|
|
Ublas : |
Subject: Re: [ublas] [patch] Move Semantics for uBlas
From: Nasos Iliopoulos (nasos_i_at_[hidden])
Date: 2009-09-15 14:22:29
>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_at_[hidden]
Date: Tue, 15 Sep 2009 13:50:07 -0400
To: ublas_at_[hidden]
Subject: Re: [ublas] [patch] Move Semantics for uBlas
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?
_________________________________________________________________
Bing brings you health info from trusted sources.
http://www.bing.com/search?q=pet+allergy&form=MHEINA&publ=WLHMTAG&crea=TXT_MHEINA_Health_Health_PetAllergy_1x1