Subject: Re: [boost] [interest] underlying type library
From: Julian Gonggrijp (j.gonggrijp_at_[hidden])
Date: 2011-08-24 07:30:22
Dave Abrahams wrote:
> on Tue Aug 23 2011, Julian Gonggrijp <j.gonggrijp-AT-gmail.com> wrote:
>> Ion Gaztañaga wrote:
>> 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?
I must admit that you do a good job at making these moves look more
similar. :-) And yes, to be fair I must say that you can probably
default-construct a new object of the same type in a raw-moved-from
But no, they are still not really the same. After a destructive move
the source object is in a destructed state (raw memory, as you say),
so in principle you should not need to worry about it anymore; i.e. it
won't be destructed again at the end of scope. You're not really
expected to store a new value of the moved-from type in the object; if
you do want to do so you'll first have to run a constructor again.
The source of a raw move on the other hand is a bomb waiting to
explode, because technically speaking it is still storing a value of
the moved-from type and it *will* be destructed at the end of scope.
Hence you are forced to give it a new, valid value.
It follows that they also have different use cases. A destructive move
seems useful for returning local variables from functions. A raw move
on the other hand can only be used if you are reordering values within
the same scope.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk