Re: [eigen] Question about the class hierarchy

[Hauke Heibel <hauke.heibel@xxxxxxxxxxxxxx>]

On Wed, Jun 30, 2010 at 6:07 AM, Manoj Rajagopalan <rmanoj@xxxxxxxxx> wrote:
> 1.   Aren't Array and Matrix independent *concepts*? Therefore, a dense matrix
> expression, which shares traits with an array expression should inherit both
> an Array base class and a Matrix base class simultaneously using multiple
> inheritance as opposed to the linearized inheritance in Eigen.

We try hard to prevent multiple-inheritance since we have encountered
examples where MSVC fails to perform empty base class optimization
which is crucial for our fixed size types.

We really want that

sizeof( Matrix<double,2,2> ) = 4*sizeof(double)

> 2.   Other matrices should inherit this Matrix base class. Then all matrices
> can be handled with matrix semantics using one base class without having to
> worry about intervening array semantics - this is what makes me most
> uncomfortable. For example, take solve() methods which accept const
> matrix-expressions as arguments. Therefore, they should accept
> DiagonalMatrix/Wrapper, SparseMatrix etc. If the solve() prototype is
> declared with MatrixBase<OtherDerived> const& as arg then we rule out this
> possibility. On the other hand, if we declare it with EigenBase<...> const&
> as arg, then it also allows Array expressions to be passed. the latter is not
> a problem if we allow it and warn the user to guard against this caveat but
> still conceptually Arrays are distinct from Vectors/Matrices ...

Maybe, looking at this document helps you a bit:

http://download.tuxfamily.org/eigen/meetings/paris2010/Gael-NewInternals.pdf

What used to be called in this document AnyMatrixBase is now our EigenBase.

> 3.   If the Array base and Matrix base must inherit EigenBase then this
> inheritance must be virtual so that there is exactly one copy of EigenBase in
> the derived object. virtual inheritance works with templates at least with
> gcc 4.2 on my linux machine.

I don't quite understand this? The EigenBase has zero size. No
members, no virtual functions. Having even a single virtual function
in EigenBase is not an option because of the sizeof constraint I told
you about before.

> 4. EigenBase seems to contain member functions that internal documentation
> warns against using. Equivalent code seems to be present in eponymous member
> function definitions of the derived classes. Then, if this makes the
> EigenBase member definitions redundant and we can remove them, this leaves
> very little in EigenBase itself - just a few methods like rows(), cols(),
> size() etc. Are we keeping these redundant definitions just so that we can
> avoid re-declaring all of these methods in the derived classes?

Yes, IIRC that is the reason. We would like to absolutely minimize
code redundancy and it comes at no cost since the compiler will
anyways perform EBO.

- Hauke