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