|
Boost : |
Subject: Re: [boost] [variant] Basic rvalue and C++11 features support
From: Vicente Botet (vicente.botet_at_[hidden])
Date: 2013-01-11 08:48:15
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-support-tp4637894p4641260.html Sent from the Boost - Dev mailing list archive at Nabble.com.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk