Re: [boost] [interest] underlying type library

Subject: Re: [boost] [interest] underlying type library
From: Dave Abrahams (dave_at_[hidden])
Date: 2011-08-24 01:28:47

on Tue Aug 23 2011, Julian Gonggrijp <j.gonggrijp-AT-gmail.com> wrote:

> Ion Gaztañaga wrote:
>
>> We still have to explore "destructive move" semantics. We have move
>> semantics. We can even declare a traits like
>> "has_trivial_destructor_after_move" to optimize a bit more vector
>> reallocations once we've moved some value_types (we avoid calling
>> destructors that do nothing useful once moved). Destructive move
>> semantics could be a step further, we need to explore destructive
>> move semantics in containers and algorithms. Some problems with
>> destructive move semantics here:
>> 
>> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2002/n1377.htm
>
> That's interesting, but after reading that page I think raw_move is
> not the same as destructive move. The difference: destructive move
> acts as a destructor and hence makes the source object unavailable for
> further use. 

Well, technically, it makes the source object's storage usable as raw
memory.

> In move_raw on the other hand, the source object is left
> in an invalid but non-destructed state which it can only be rescued
> from by raw moving another value into it (if it is non-POD).

How is an "invalid but non-destructed state" practically different from
raw memory?  Are you saying I can't default-construct another value of
the same type in that memory?

-- 
Dave Abrahams
BoostPro Computing
http://www.boostpro.com