Re: [boost] [interest] underlying type library

Subject: Re: [boost] [interest] underlying type library
From: Julian Gonggrijp (j.gonggrijp_at_[hidden])
Date: 2011-08-24 15:21:40

Dave Abrahams wrote:

> on Wed Aug 24 2011, Julian Gonggrijp <j.gonggrijp-AT-gmail.com> wrote:
> 
>> 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)

No, I was wondering (and sceptical) about that already.

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

Yes, that's what I meant to say.

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

So what you are saying is: in practice there is no difference between 
a raw move and a destructive move. Point taken. But in that case the 
name 'raw move' seems to cover the semantics much better than 
'destructive move'.

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

Correct. 'Within the same scope' was meant to refer to the reordering, 
not to the values. That is, once you start a chain of raw moves, you 
have to close that chain within the same scope in order to provide a 
validity guarantee to calling clients.

With hindsight, I should have realised much earlier in this thread 
that this is also the reason why every operation between the start and 
the end of a chain of raw moves must be exception-free.

-Julian