|
|
Ublas : |
Subject: Re: [ublas] [patch] Move Semantics for uBlas
From: Jesse Perla (jesseperla_at_[hidden])
Date: 2009-09-15 13:50:07
On Tue, Sep 15, 2009 at 9:49 AM, Nasos Iliopoulos <nasos_i_at_[hidden]>wrote:
> The problem with bounded_... and c.. is that they allocate space into the
> stack, so swaping needs to actually copy their elements, hence nullifying
> the effects of move semantics. I think for the bounded_.... classes changing
> from ownership of the underlying container to a pointer to them (and
> necesseary changes in construction, destruction and swap), will do it (We
> can right? my mind is not looping here?). For the c_.... we will probably
> need to introduce boost::array. The important thing is to keep them into the
> stack.
>
> But if has a pointer to them, how do we have it statically allocated? I
must be missing something. On the other hand, if something is created on
the stack, the compilers still can do copy elision (e.g. the make_ pattern
for object constructor functions), so I am thoroughly confused by this
stuff. Maybe these would already have copy elision with optimizations on?
Is there anyway to check this? It seems that as soon as we do anything to
the pointer in the function to display it, the compiler would stop doing the
elision...
I read this a while back, but didn't understand it well enough:
http://cpp-next.com/archive/2009/08/want-speed-pass-by-value/
> Also, rvalue reference is not a cure for everything. Even with that,
> bounded_... and c_... will not be move semantics enabled. Although a first
> effect of c++0x rvalue references will be that we can enable
> prod(A,prod(B,prod(C,prod(D,F)))) without unnecesarry copies.
>
Well, that is pretty damn useful itself. People would love to have that
prototype, and coupled with operator* overloading, ublas is getting a pretty
powerful interface. Is it hard to implement?