Re: [eigen] Re: VectorBase issue

["Gael Guennebaud" <gael.guennebaud@xxxxxxxxx>]

> to get back to VectorBase, the motivation of VectorBase was two folds:
>  1 - better API by hiding vector specific methods from matrix expressions
> (aka compile time errors).
>  2 - faster compilation for matrix code.
> Another minor advantage is that all vector specific methods get grouped in
> a separate class.

I just had another idea. The correct solution to your problem 2b is probably
that, if you are going to put vector-specific methods in VectorBase<true>
then you could as well put matrix-specific methods in VectorBase<false>. So
that they would never be in conflict with one another. (of course the naming
could be improved, MatrixBase becomes XprBase, VectorBase<true> becomes
VectorBase, VectorBase<false> becomes MatrixBase, VectorBase itself becomes a
meta-selector).

What do you think?

In fact I believe this is the correct C++ solution. The only issue that I see
is that it's going to be difficult to make Doxygen understand that!

I've
though about that option too (solution 2-c), this would be very good
for compilation time, the problem is when you write a generic code for
fixed-size matrices: you might (easily?) end up with degenerated
matrices that becomes vector (or 1x1 matrices), that means
coeff(int,int), corner(...), block(int,int,int,int), etc. must be
available even if the matrix has one dimension equals to 1 ? in other
words, a matrix is not necessarily a vector (=>VectorBase), but a
vector *is* a matrix, isn'it ? e.g., currently there is no
assert(!IsVectorAtCompileTime)...

However, internally we can use VectorBase<false> versus  VectorBase<true>  to avoid the need of meta selector. I did that for isApprox and similar fuzzy stuff before giving up with VectorBase (MatrixBase::isApprox call this->isApproxImpl that is defined in one of the VectorBase specialization).

there is still the option 2-a....