2011/8/17 Frank Mori Hess :

I have some rather indefinite plans to add move support, at least when compiling in c++0x mode. A swap function for signals2::signal() could be added to make a poor man's move possible for non c++0x code.  I'm not sure I want to bother with move emulation.

Making things movable is super easy with boost.move and it would be very useful feature imho. Using swap() for moving is preferred way to implement move ctor/assignement anyway no matter how rvalues are implemented (if it is actual support or emulation mode). I now keep noncopyable objects in boost::container::vector and those objects have signal members which have to be kept with shared_ptr<> only to be able to transfer ownership.

I'm not promising to do any of this in the immediate future though.  So if you are impatient, patches are welcome.

OK, will try to do that. -- Szymon Gatner

2011/8/27 Dave Abrahams :

No, it's the easiest way to get move assignment semantically correct, but not "the preferred way."  At least, it's not universally preferred. See http://cpp-next.com/archive/2009/09/your-next-assignment/

Thanks, great read! I am still trying to fully understand all implications of move semantics. For example: is std/boost::move() killer of potential RVO? I mean: std::vector<int> getNumbers() { std::vector<int> ret; // fill data return move(ret) // will that kill potential (N)RVO? } Regards, Szymon

on Mon Aug 29 2011, Christopher Jefferson wrote:

On 29 Aug 2011, at 14:04, Szymon Gatner wrote:

...

2011/8/27 Dave Abrahams :

...

No, it's the easiest way to get move assignment semantically correct, but not "the preferred way." At least, it's not universally preferred. See http://cpp-next.com/archive/2009/09/your-next-assignment/>>

Thanks, great read! I am still trying to fully understand all implications of move semantics. For example: is std/boost::move() killer of potential RVO?

I mean:

std::vector<int> getNumbers() { std::vector<int> ret;

// fill data

return move(ret) // will that kill potential (N)RVO? }

std::move does not hurt RVO in compilers I have tried it in. boost::move, when emulating move semantics in C++03, does seem to confuse RVO in some situations (sorry if that is a bit vague, I did not do a full and complete investigation).

Also note: C++11 inserts the move there implicitly, so you never need to write "return move(...)" -- Dave Abrahams BoostPro Computing http://www.boostpro.com