Neal,
the pattern works as follows:

1. For compilers that elide:
a. Passing by value, the arguments will be either moved inside a function (if the function doesn't modify them) or not (if it does modify them). For assignment operations either is what we would like to happen. And it is unlikely that an assignment will try to change the argument, unless it is the same as the assignee, in which case nothing happens.
b. By employing light swap functions (i.e. like ublas' assign_temporary) there is no copy when "this" accepts the storage.
The above pattern is similar as been passed by reference, but without the need for an extra temporary copy operation, since source and destination are guaranteed to be different.

2. For compilers that do not elide.
a. Passing by value, copies the source object into the function regardless.
b. The passed value is again assigned to a temporary and swaped.
This situation is equivallent as the one currently supported in boost (passing by const reference and assigning through a temporary and a copy). The difference is that the copy happens first and the temporary is assigned afterwords.

To sum up:
For elision enabled compilers, assignment doesn't need a copy.
For no-elision enabled compilers, assignment works as it works now.

With gcc 4.3.3 (it does elision), you can see the benefits of 1, in the pointers outputed before and after the assignment operation for ONLY matrix<T> and vector<T>. (in the test program I provided)
i. With BOOST_UBLAS_MOVE_SEMANTICS, the pointers are the same (i.e. the underlying objects have been swaped and no copy is performed)
ii. Without BOOST_UBLAS_MOVE_SEMANTICS, the pointers are different (i.e. the assignment has been done through a temporary and a copy).

(ii) is the current situation in uBlas and (i) is with the proposed patch.

Hope that answers your questions
Best
Nasos

> To: ublas@lists.boost.org
> From: ndbecker2@gmail.com
> Date: Tue, 15 Sep 2009 07:20:30 -0400
> Subject: Re: [ublas] [patch] Move Semantics for uBlas
>
> I haven't studied this in any detail. Do I understand correctly that this
> is an optimization for compilers that don't elide constructors?
>
> I have tested a few times in the past the modern gcc will elide
> constructors, and returning containers by value does not cause unneeded
> copies.
>
> Is the point of this only to allow containers to be returned by value, or is
> there more to it?
>
> _______________________________________________
> ublas mailing list
> ublas@lists.boost.org
> http://lists.boost.org/mailman/listinfo.cgi/ublas
> Sent to: nasos_i@hotmail.com


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