D's equivalent to C++'s std::move?

[Lars T. Kyllingstad via Digitalmars-d]

On Saturday, 13 February 2016 at 22:42:34 UTC, Ola Fosheim 
Grøstad wrote:
> On Saturday, 13 February 2016 at 21:41:06 UTC, Lars T. 
> Kyllingstad wrote:
>> Whose expectations?  The formal expectation, as per the C++ 
>> standard, is that the moved-from object be left in a "valid 
>> but unspecified state".  Basically, as long as it is safe to 
>> destroy or reassign to the moved-from object, you're good.
>
> Hmm, do you have a reference (URL) to the "valid but 
> unspecified state" part? I'm not quite sure what that refers to.

I know you said afterwards you didn't need a reference, but I'll 
give you one anyway. :)  That is the formal requirement for C++ 
standard library types; see sec. 17.6.5.15 [lib.types.movedfrom] 
of the C++ specification.

But I agree that, for the most part, one would expect that the 
moved-from object holds *no* resource and that the resource 
previously held by the target object has been released.


>> I hope this is not coming across as me endorsing the practice 
>> of implementing move assignment in terms of swap, because I 
>> don't.  But it *is* a rather common practice, enough so that 
>> Scott Meyers felt the need to write an article about it:
>
> I've never heard of it, and never thought it would be a good 
> idea. Are you sure this is common?

Pretty sure, but off the top of my head I can't give you too many 
concrete examples beyond the Meyers article I linked to, Stack 
Overflow questions, and one particular well-known and respected 
library (ZeroMQ) where I recently ran into it.


>> A swap is three moves -- actual moves.
>
> If you are talking std::swap, probably. Never use it, so don't 
> know if there is any measurable overhead.

I was, yes.


> If you are talking about the microcode in the CPU, then it 
> typically takes 2 loads and 2 stores to swap two pointers on 
> the heap, and the loads and stores can execute in parallel... 
> So performance wise, not a big deal. But with 
> debugging/consistency in mind you should set the source to 
> nullptr instead.
>
> I know programmers talk alot about swap being implemented as
>
> tmp = a
> a = b
> b = a
>
> But that is actually how it is specified it source code, not 
> how it is implemented in running code. In the CPU it goes like 
> this:
>
> reg1 = load a; reg2 = load b
> b = store reg1; a = store reg2
>
> Setting it to null would be almost the same.
>
> reg1 = load a; reg2 = 0
> b = store reg1; a = store reg2
>
> Unless you use special commands and zero out the entire 
> cacheline of "a" you still get the same amount of cache-misses 
> as well.

For your lowest-level resource owners, I guess that is the case.  
But if a and b are largeish compound types that don't fit in a 
register, that's not the case, right?  Or can the optimiser deal 
with this in a good way too?


> Well, if you have a back pointer that is part of the invariant 
> for the type, then neither move or copy work as expected. In 
> C++ you have the address of the source object and can either 
> modify or change the associated data-structure that provide 
> back pointers (e.g. a global hash with pointers to the struct, 
> in C++ you can change these pointers to point to the new 
> location/add another entry). AFAIK this is not possible in D 
> without adding an indirection.

So what you're saying that a particular kind of designs/patters 
can not be safely combined with D's standard move mechanism.  
That is of course very unfortunate, but I guess it can be worked 
around?  I thought you were implying that simply using move() on 
any struct could potentially mess it up...