On 1/21/13 10:29 PM, Andrey Semashev wrote:
On Mon, Jan 21, 2013 at 5:39 PM, Antony Polukhin <antoshkka@gmail.com> wrote:
[snip]
II: Set operand.p_ to NULL, add BOOST_ASSERT in get operations + good performance + provides noexcept guarantee for move constructor + optimization will be used even if varinat has no type with trivial default constructor + easy to implement - triggers an assert when user tries to reuse moved object - adds an empty state to the recursive_wrapper
I'd prefer this option. IMHO, one of the major points of move semantics is optimization and moved-from objects are as good as dead anyway; I wouldn't even try to revive a moved-from object with assignment. But this is a breaking change (is it?), so it should have a prominent note in release notes.
No it's not (a breaking change). We don't have move prior to this patch. The only issue is the one Paul Smith notes regarding conservative move and that is only relevant in the extremely rare case when someone tries to do something to a moved-from object. This notion of a "valid" state is not clear to begin with anyway and many say it depends on the library to define what "valid" means. The case of NaN is a very clear example of a perfectly "valid" state similar to what we have here. To require that an object not have such preconditions on operations after move will have a negative impact on optimizations such as this. Me? You know my vote. But Peter's suggestion (III) is also an acceptable route. Regards, -- Joel de Guzman http://www.boostpro.com http://boost-spirit.com