Re: [eigen] const-correctness in Eigen 3.0

[Benoit Jacob <jacob.benoit.1@xxxxxxxxx>]

2010/10/26 Christoph Hertzberg <chtz@xxxxxxxxxxxxxxxxxxxxxxxx>:
> Hi,
>
> great not to be alone with this issue :)

You guys are not alone --- that's why I marked this bug as 'critical'.

It's just that this week we've been working on other issues, e.g. the
internal:: namespace.

Yes, let's continue discussion on this bug. But I wasn't planning to
work on that immediately.

Benoit

>
> On 26.10.2010 04:18, Jim Bosch wrote:
>> I've been following the occasional discussions regarding the
>> const-incorrectness of Map (and Block, Transpose, etc.) with interest; I
>> once put a lot of effort into getting this right in my own
>> template-based multidimensional array library, and I'd love to see this
>> get fixed in Eigen.
>>
>> I'd be happy to put some effort into fixing this in Eigen 3.0, but as a
>> relatively new face (well, I've been lurking a long time!) tackling a
>> fairly widely-dispersed issue, I wanted to get some discussion going
>> instead of just going out and making a giant patch.
>>
>> First off, here's what I think the solution should look like:
>>
>>  - Matrix and Array (and other PlainObjectBase subclasses) should pretty
>> much behave as they do currently.
>>
>>  - Map, Block, Transpose, and anything else that does not own its data
>> but supports direct access should come in both const and non-const
>> versions (probably just partial specializations).  The non-const version
>> should be implicitly convertible to the const version.
>>
>>  - Calling block() or transpose() on a const reference to Matrix should
>> return a const Block or const Transpose(), etc.
>
> I think you mean sth like const_Block<...> or Block<const ..., ...>. The
> const qualifier outside the class (as it is currently done) helps
> little, as you can still construct/assign:
>
>  const Block<...> a;
>  Block<...> b(a);
>
> This could be avoided by prohibiting the copy constructor etc, but this
> would prohibit some legal copies. (Sorry for repeating this, I assume
> you already know ...)
>
>> What I think this implies:
>>
>>  - MatrixBase, ArrayBase, DenseBase, DenseCoeffsBase, and EigenBase
>> should also have partial specializations for const and non-const; the
>> non-const version should probably inherit from the const version in some
>> cases for code reuse, just adding non-const accessors and augmented
>> assignment operators.
>>
>>  - PlainObjectBase should inherit from a non-const base class.
>>
>>  - Expressions that don't have direct access should inherit from the
>> const MatrixBase or ArrayBase.
>>
>>  - There should probably be a flag for constness on every Eigen class.
>>
>>
>> I anticipate these changes would be fairly straightforward, but they are
>> very extensive.  I don't seen any easier way to get const-correctness in
>> place in a consistent way, however, and I think doing it now will pay
>> off in the long run.
>>
>> Any thoughts?
>
> I've also been thinking about this, my general idea was based on also
> solving the direct-access-type unification
> http://eigen.tuxfamily.org/bz/show_bug.cgi?id=58
>
> The basic idea is to have a new (internal?) type direct_access with
> template types for storage and for indexing.
>
> template<class Storage, class Indexing>
> class direct_access : Indexing {
>  Storage storage;
> public:
>  Storage::Scalar& operator(int i, int j) {
>    // not valid if Storage is a const-view:
>    return storage[Indexing::offset(i, j)];
>  }
>  // etc ...
> };
>
> The Storage class could be either a dynamic array, a static array, a
> pointer or a const pointer -- and the Storage class would maintain the
> const-correctness (i.e. it's illegal to assign to the const pointer type)..
>
> The Indexing type would calculate indexes to a relative offset and could
> be zero-sized if everything is known at compile time.
> Theoretically Indexing could also handle cases like compressed
> triangular storage (though handling of implicit cases would need some
> thought):
> http://listengine.tuxfamily.org/lists.tuxfamily.org/eigen/2010/07/msg00198.html
>
>
> Somewhat off-topic:
> Is there a reason why currently it is not possible to have fixed size
> matrices with dynamic memory allocation? (Or is it?)
> A use case would be a 32x32 matrix, which you suggest not to store as
> fixed size type (can't find a reference now). However, storing this as
> dynamic matrix would waste (not much but some) memory, and also
> prohibits some compile-time assertions.
>
> Regards
> Christoph
>
>
> --
> ----------------------------------------------
> Dipl.-Inf. Christoph Hertzberg
> Cartesium 0.051
> Universität Bremen
> Enrique-Schmidt-Straße 5
> 28359 Bremen
>
> Tel: (+49) 421-218-64252
> ----------------------------------------------
>
>
>