Re: [boost] [interest] underlying type library

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

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

> Dave Abrahams wrote:
>
>> 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 
> object.
>
> 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. 

Do you know how to implement that? (hint: see below)

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

No, it is *not* storing a value.  I believe you're saying that the
difference is not in the state of the memory, but in what the compiler
will try to do with that memory later.  That requires you to believe
that in general, the compiler can know about the state of a
destructively-moved automatic object and avoid destroying it again.
But, for all practical purposes, it can't.  In general, that requires a
bit of storage and a runtime check for each object that might be moved
from.

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

But that optimization is almost completely unneeded because of RVO.  And
when RVO doesn't kick in and a real move is needed, the compiler may be
able to detect that it's just fixing up an object that's about to be
destroyed.

> A raw move on the other hand can only be used if you are reordering
> values within the same scope.

? I presume that I can do swap(x,y) no matter what x and y's scope are.

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