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.

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.
The standard is getting its final wording and hopefully there will be a semi-final edition for all of us to follow soon.

I may post some c++0x code, just for mind feeding.

Best
Nasos

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

On Mon, Sep 14, 2009 at 10:59 PM, Nasos Iliopoulos <nasos_i@hotmail.com> wrote:

Dear all,
An immediate effect of this patch is the elimination of the need for noalias in types vector<T> and matrix<T>, when assigned to the same type. Although this patch implements move semantics for bounded_ and c_ (vector and matrix) types, they don't have any effect at those types, due to their underlying storage. I included it for possible future exploitation.

Nasos:
This is great, I look forward to playing with it.

What is involved for doing this for bounded_ ? I use them all over the place. Is it tough to do this with C++03 but easier with rvalue references? If so, I don't mind requiring the necessary C++0X features (my target compilers already support it).

Thanks,
Jesse

Ready for Fall shows? Use Bing to find helpful ratings and reviews on digital tv's. Click here.