>But if has a pointer to them, how do we have it statically allocated?  I must be missing something. 

You are right, my bad, what was I thinking?

> Is it hard to implement?

Move constructor in vector.hpp:
1...................

BOOST_UBLAS_INLINE

vector (vector &&v):

vector_container<self_type> ()

{ data_.swap(v.data());}


2.................
and when you implement a function, you do it somehow like that:

ublas::vector<double> doubleit(ublas::vector<double> &&m)

{

m*=2.0;

std::cout << "Temporary pointer: " << &m[0] << std::endl;

return std::move(m);

}


If you do those changes in the files I uploaded, you  can get:

a = doubleit(doubleit(doubleit(doubleit(a))));

with absolutely no copy.

Note: I have not invested enough time thinking of the above and any side effects it may have, although it shouldn't.

And again it will work only for matrix and vector types, not bounded and c types.

(compile with -std=gnu++0x)

Cheers
Nasos



From: jesseperla@gmail.com
Date: Tue, 15 Sep 2009 13:50:07 -0400
To: ublas@lists.boost.org
Subject: Re: [ublas] [patch] Move Semantics for uBlas


On Tue, Sep 15, 2009 at 9:49 AM, Nasos Iliopoulos <nasos_i@hotmail.com> 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?


Bing brings you health info from trusted sources. Try it now!