what to do with postblit on the heap?

[Michel Fortin]

On 2011-06-21 12:13:32 -0400, so <so at so.so> said:

> On Tue, 21 Jun 2011 18:18:26 +0300, Michel Fortin  
> <michel.fortin at michelf.com> wrote:
> 
>> Actually, no copy is needed. Move takes the argument by ref so it can  
>> obliterates it. Obliteration consists of replacing its bytes with those 
>>  in S.init. That way if you have a smart pointer, it gets returned  
>> without having to update the reference count (since the source's 
>> content  has been destroyed). It was effectively be moved, not copied.
> 
> T move(ref T a) {
>    T b;
>    move(a, b);
>    return b;
> }
> 
> T a;
> whatever = move(a);
> 
> If T is a struct, i don't see how a copy is not needed looking at the  
> current state of move.

Actually, that depends on how you look at this.

The essence of a move operation is that you just copy the bits and then 
obliterate the old ones. So yes, there's indeed a copy to do, but 
there's no need to call a copy constructor or a destructor because no 
new instance has been created, it has just been moved. If you don't 
call the copy constructor (postblit) then it's a move operation, not a 
copy operation, even though there's still a bitwise copy inside the 
move operation.

In the return statement above, 'b' gets copied to 'whatever', then 
disappears along with the stack frame belonging to the function. So it 
becomes a move operation. (And it's even more direct than that with the 
named-value optimization.)

-- 
Michel Fortin
michel.fortin at michelf.com
http://michelf.com/