Boost logo

Boost :

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 <> 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:
> 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

> 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

Boost list run by bdawes at, gregod at, cpdaniel at, john at