Re: [eigen] Re: VectorBase issue

[ Thread Index | Date Index | More lists.tuxfamily.org/eigen Archives ]


On Wednesday 04 June 2008 14:27:19 Gael Guennebaud wrote:
> On Wed, Jun 4, 2008 at 12:03 AM, Benoît Jacob <jacob@xxxxxxxxxxxxxxx> wrote:
> > > Actually I think this is good in general since
> > > it allows to overload a MatrixBase member in Derived, and the proper
> > > overload will be called.
> >
> > Sorry, I don't understand what you mean. Can you explain?
>
> This is a general problem that is not only related to VectorBase:
> The point is the following: let's assume an expression (the Derived class)
> overload the method inverse() (like Quaternion). Then you have a templated
> method foo which takes an expression like this:
> template<typename OtherDerived> void foo(const MatrixBase<OtherDerived>&
> other) {
>   blabla;
>   blabla   other.inverse() blabla;
>   blabla;
> }
>
> then the correct overload won't be called...

ah, now I understand. I had stumbled upon exactly the same problem when 
thinking about how to do a quaternion class.

> instead you could define foo e
> to directly takes a "const OtherDerived&" (but that's not nice because too
> generic) or systematically call .derived() to MatrixBase<> object:
> other.derived().inverse()
> that is, IMO, in the spirit of the CRT pattern...

I hadn't thought of this solution. It seems very good.

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

> For the first point, after a chat with Benoit, we agreed to add support for
> compile time checks using custom static_assert (see recent commit).
> This solution is more general since it allows any kind of compile time
> checks. However that doesnot make MatrixBase lighter for matrix and so no
> compile time gain...

If you believe that separating the vector-specific and matrix-specific APIs 
can improve compilation speed, and if we find a way to do that without 
hurting our API, then it's worth it :)

Benoit

Attachment: signature.asc
Description: This is a digitally signed message part.



Mail converted by MHonArc 2.6.19+ http://listengine.tuxfamily.org/