what to do with postblit on the heap?

[Jonathan M Davis]

On 2011-06-20 16:07, Steven Schveighoffer wrote:
> On Mon, 20 Jun 2011 18:43:30 -0400, Jonathan M Davis <jmdavisProg at gmx.com>
> 
> wrote:
> > On 2011-06-20 15:12, Steven Schveighoffer wrote:
> >> BTW, I now feel that your request to make a distinction between move and
> >> copy is not required. The compiler currently calls the destructor of
> >> temporaries, so it should also call postblit. I don't think it can make
> >> the distinction between array appending and simply calling some other
> >> function.
> > 
> > If an object is moved, neither the postblit nor the destructor should be
> > called. The object is moved, not copied and destroyed. I believe that
> > TDPL is
> > very specific on that.
> 
> Well, I think in this case it is being copied.  It's put on the stack, and
> then copied to the heap inside the runtime function.  The runtime could be
> passed a flag indicating the append is really a move, but I'm not sure
> it's a good choice.  To me, not calling the postblit and dtor on a moved
> struct is an optimization, no?  And you can't re-implement these semantics
> for a normal function.  The one case I can think of is when an rvalue is
> allowed to be passed by reference (which is exactly what's happening here).

Well, going from the stack to the heap probably is a copy. But moves shouldn't 
be calling the postblit or the destructor, and you seemed to be saying that 
they should. The main place that a move would occur that I can think would be 
when returning a value from a function, which is very different. And I don't 
think that avoiding the postblit is necessarily just an optimization. If the 
postblit really is skipped, then it's probably possible to return an object 
which cannot legally be copied (presumably due to some combination of 
reference or pointer member variables and const or immutable), though that 
wouldn't exactly be a typical situation, even if it actually is possible. It 
_is_ primarily an optimization to move rather than copy and destroy, but I'm 
not sure that it's _just_ an optimization.

> Is there anything a postblit is allowed to do that would break a struct if
> you disabled the postblit in this case?  I'm pretty sure internal pointers
> are not supported, especially if move semantics do not call the postblit.

If the struct had a pointer to a local member variable which the postblit 
would have deep-copied, then sure, not calling the postblit would screw with 
the struct. But that would screw with a struct which was returned from a 
function as well, and that's the prime place for the move semantics. That sort 
of struct is just plain badly designed, so I don't think that it's really 
something to worry about. I can't think of any other cases where it would be a 
problem though. Structs don't usually care where they live (aside from the 
issue of structs being designed to live on the stack and then not getting 
their destructor called because they're on the heap).

- Jonathan M Davis