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...
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?