Re: [eigen] const-correctness in Eigen 3.0

[Christoph Hertzberg <chtz@xxxxxxxxxxxxxxxxxxxxxxxx>]

Hi,

great not to be alone with this issue :)

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
----------------------------------------------