Re: [boost] [optional] swapping initialized with uninitialized

From: Ulrich Eckhardt (doomster_at_[hidden])
Date: 2006-03-12 14:28:13

On Saturday 11 March 2006 20:19, Václav Veselý wrote:
> Ulrich Eckhardt wrote:
>> On Friday 10 March 2006 17:14, Vaclav Vesely wrote:
>>> When two optionals (one initialized and other not) are swaped, then 
>>> the one value in uninitialized optional is constructed and the other 
>>> one in initialized optional is destructed.
>>>
>>> IMHO it's not necessary. It should be more effective to swap optional's
>>> m_storages without any values constructiona and destruction.
>
> ...
>
>> It could only be done if the object was moveable, i.e. depending on a
>> type_trait. Looking at the Boost type_traits library, I wonder why this
>> trait doesn't exist - many things can be sped up using memcpy when 
>> is_pod is true, but even things like vector/string/deque 
>> (list/map/set depending on whether their root node is stored by 
>> pointer) can be moved in memory without negative effects (yes, talking
>> about typical implementations here, not guarantees).
>
> I see now. But IMHO is_pod is not satisfactory condition for is_movable.
> For example the class
>
> struct X
> {
> 	X* me; // Can points to the instance
> };
>
> seems to be POD, but it's not movable.

Well, in the case that 'me' must always be equal to 'this', then this thing is 
not even copyable. Otherwise, if it had a ctor/cctor, it wouldn't be a POD 
anymore. PODs can be copied using memcpy(), so, as my arguing goes, they can 
also be moved that way.

> The best implicit implamentation is probably the has_trivial_copy trait.

I agree, has_trivial_copy catches all PODs but also a few more that are not 
PODs e.g. because they have a nontrivial ctor or dtor.

> I think it worth it. For example I use optional<string> frequently. If you
> think that the is_movable trait is good enogh for Boost I would like write
> it including test and documentation.

I also do think it is worth it (note to self: see if STLport has it already, 
think about std::vector), what do others think?

Uli