Re: [eigen] Eigen Types as Parameters for Functions

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


On 27.06.2012 17:33, Gael Guennebaud wrote:
On Wed, Jun 27, 2012 at 3:16 PM, Christoph Hertzberg
<chtz@xxxxxxxxxxxxxxxxxxxxxxxx> wrote:
[...]
I just noted that, unfortunately, the copy-back will not be as simple to
implement as I thought, because you don't have the type of Derived available
in the destructor.

Maybe Ref<> could store the address of a copy back function
"generated" through templates by the compiler. This copy-back function
would start by doing a void* to Derived* reinterpret_cast and then
does the job. Sounds a bit complicated though.


Nice idea, kind of like a hand-made virtual destructor.
I agree though that's a bit complicated. The user might not notice that, however he might get unexpected overhead in some cases.

In my current approach [1] (limited to non-strided vectors) I do not allow
copy-backs, and I currently need to pass expression.eval(), if expression
itself is not a direct-access expression -- saving the m_object member at
the cost of less elegant code in this case.


[1]
https://openslam.informatik.uni-freiburg.de/data/svn/MTK/trunk/cpp/mtk/src/vectview.hpp

Sure, enforcing users to explicitly call eval() solves a lot of
problems for us (including the one below), but is more painful for the
users.

Yes, unfortunately C++ can't do a two-stage implicit conversion (convert expression to MatrixXd, and MatrixXd to Ref<const MatrixXd> etc.) -- I see though that if it was possible, it could cause a lot of ambiguities.


Wouldn't it be possible to pass a const Ref<>& instead of passing Ref by
value? You could make all assignment functions of Ref be const w/o losing
const-correctness, as they would not modify Ref itself, but the referenced
object (which itself has an optional const-modifier).
A draw-back of this solution is that another stage of dereferencing is
required.

That's the solution I wanted to suggest. I proposed to pass the Ref<>
objects by value mostly because it looks better for writable
arguments. Having a "const Ref<VectorXf>&" writable is a bit
dangerous. But if we agree that copy-back is a no go, then the
internal m_object will exists only for const version so one could pass
by a const reference for const arguments, and by value for writable
ones.

Yes, sounds like a plan. This should cause no overhead if the m_object is not required, just some temporary stack space. Furthermore, this can then be used for (fixed size) aligned references as well, copying the expression, iff it is not aligned at compile-time.


Christoph




--
----------------------------------------------
Dipl.-Inf. Christoph Hertzberg
Cartesium 0.049
Universität Bremen
Enrique-Schmidt-Straße 5
28359 Bremen

Tel: +49 (421) 218-64252
----------------------------------------------





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