Hartmut Kaiser wrote
On 1/8/13 4:14 AM, Paul Smith wrote:
Joel de Guzman wrote:
Hi,
I just looked at the current state of variant and noticed that the implementation of recursive_variant's move ctor seems to be not as optimal as I hoped. The current implementation as written is:
recursive_wrapper <T> ::recursive_wrapper(recursive_wrapper&& operand) : p_(new T( detail::variant::move(operand.get()) )) { }
Do you see something that I don't?
Without this move optimization (as it currently is), it is very inefficient especially with big structures (e.g. tuples and fusion adapted structs). Without this optimization, such temporary copies will end up with two heap allocations and unnecessary copying of the structures, instead of one heap allocation and a simple pointer swap. That would mean the missed optimization in the order of magnitudes with applications that use variant heavily (e.g. Spirit).
I agree 100% with Joel. Move construction means move construction - i.e. the source object is by definition left in a zombie state. No harm done. What's the point in having a move constructor which essentially is equivalent to a copy constructor in the first place?
I have not see the code using recursive_wrapper. Do we really need recursive_wrapper to be movable? if yes, in which cases this optimization is a must have? Best, Vicente -- View this message in context: http://boost.2283326.n4.nabble.com/variant-Basic-rvalue-and-C-11-features-su... Sent from the Boost - Dev mailing list archive at Nabble.com.