Re: [eigen] still the solve() API debate

[ Thread Index | Date Index | More Archives ]

On Fri, Sep 11, 2009 at 5:17 PM, Benoit Jacob <jacob.benoit.1@xxxxxxxxx> wrote:
> OK, coming back to seriousness: I like your idea, I'm just not sure
> about the INOUT name. Maybe the more verbose EIGEN_REF_TO_TEMPORARY
> would be more explicit as to what it does and why we have to do it?

Of course, anything would be fine here...

> +1 to Hauke's idea to keep rvalue refs in mind;

Actually Gael's, I just moved the const. :)

Ok, I just did some reading (this is a cool article:
and then I recalled something from "Effective STL" which confused me a
bit. One item in "Effective STL" deals with "the swap trick" to trim
the capacity of std::vector....

Now I was wondering how this should work facing the rvalue issue we
are having with swap since the idea is to swap a vector with a
temporary rvalue object that is empty. After looking at the
std::vector::swap implementation I recognized that it is implemented
as expected with a non-const reference, so how can this work? Well,
swap is commutative and what they do is simply to put the rvalue
object on the left-hand-side like this:

std::vector<double> v(10000,1.0);
std::vector<double>().swap(v); // as opposed to ...
// v.swap(std::vector<double>())

So, now I am just asking... could we not just use void
MatrixBase::swap(MatrixBase<OtherDerived>& other) and force the user
to use e.g.

MatrixXf a,b,c;

I am just wondering...

Going back to the solve API. What about

MagicReturnType<...> solve(const MatrixBase<...>& b) const; // and
void solve(MatrixBase<...>& b) const;

For the first one we may pass rvalue objects and everything is fine
and for the second one, well, rvalue objects don't make any sense...
so here we don't care.


Mail converted by MHonArc 2.6.19+