Subject: Re: [ublas] Move Semantics
From: Jesse Perla (jesseperla_at_[hidden])
Date: 2009-09-07 11:13:34
On Wed, Sep 2, 2009 at 2:29 PM, Gunter Winkler <guwi17_at_[hidden]> wrote:
> > Also, I see that this is native to MTL:
> in ublas the move semantics is partially available:
> A.assign_temporary( same type as A )
> this is implemented by swapping the internal storage objects.
> if B in very large than it is already very expensive to compute inv(B).
> In order to optimize this we had to modify the inv() method to return an
> expression template instead of acutally computing the result. Then the
> computation is deferred until the assignement to A is executed. However
> this only helps if we can easily compute the rhs expression element by
> Yup. And as you say, that isn't the case here (or in many places where we
end up using the bindings...)
> > If this pattern is not usable yet, any idea of when it would be?
> for inversions of general matrices I see no option except the usual
> "decompose" and "solve" strategy which must be coded explicitly.
> True, but somehow the MTL4 guys have move semantics working so that you can
return the matrix expression... Might be worth checking out their
So let me throw out the following idea:
1) People really want functional style returns, for all of the usual
2) I think that there are a lot of people using compilers with C++0X
support, especially in numerics. Intel 11.1 supports auto, decltype, and
rvalue references. GNU already has it. And MSVC 2010 with have all of
these as well. I think it is reasonable to have some features that
selectively turn features on based on compiler support.
3) Boost::move seems to be getting there...
so it might even be possible to get stuff working with C++03.
So, with all that said... is a possible solution to the return value thing
to implement rvalues constructors, etc. for the matrix and vector
Could we have a preprocessor instruction that generates the rvalue
implementations? Can the assign_temporary() be used here to make the code
If the assign_temporary only works for expressions of the same type, it
might not work so well, but thought I would throw out the idea. This
feature would be almost as important as the operator* overloads for