[Signals\Signals2] Move semantics
Hi, Any plans to do signals\signals2 movable? Just getting used to move things with great boost.move + boost.container libraries and being able to do same with signal-related code would be really nice as now the only way to deal with that is to keep signals on the heap which I find rather awkward. Cheers, Simon
On Monday, August 15, 2011, Szymon Gatner wrote:
Any plans to do signals\signals2 movable? Just getting used to move things with great boost.move + boost.container libraries and being able to do same with signal-related code would be really nice as now the only way to deal with that is to keep signals on the heap which I find rather awkward.
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. As an aside, I'm also thinking of doing some more reference counting so that user's slot objects will get destroyed more promptly after they are disconnected (as soon as they are no longer being executed by any concurrent signal invocations). It will add a bit of overhead (at least 1 extra mutex lock/unlock per signal invocation) but people seem to find the current garbage collection of slot objects surprising. I'm not promising to do any of this in the immediate future though. So if you are impatient, patches are welcome.
2011/8/17 Frank Mori Hess <fmhess@speakeasy.net>:
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
on Sat Aug 27 2011, Szymon Gatner <szymon.gatner-AT-gmail.com> wrote:
2011/8/17 Frank Mori Hess <fmhess@speakeasy.net>:
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).
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/ -- Dave Abrahams BoostPro Computing http://www.boostpro.com
2011/8/27 Dave Abrahams <dave@boostpro.com>:
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 29 Aug 2011, at 14:04, Szymon Gatner wrote:
2011/8/27 Dave Abrahams <dave@boostpro.com>:
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). Chris
on Mon Aug 29 2011, Christopher Jefferson <chris-AT-bubblescope.net> wrote:
On 29 Aug 2011, at 14:04, Szymon Gatner wrote:
2011/8/27 Dave Abrahams <dave@boostpro.com>:
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
participants (1)
-
Christopher Jefferson -
Dave Abrahams -
Frank Mori Hess -
Szymon Gatner