Move semantics for D

Christophe Travert travert at phare.normalesup.org
Fri Jul 13 01:59:27 PDT 2012


Benjamin Thaut , dans le message (digitalmars.D:172207), a écrit :
> Move semantics in C++0x are quite nice for optimization purposes. 
> Thinking about it, it should be fairly easy to implement move semantics 
> in D as structs don't have identity. Therefor a move constructor would 
> not be required. You can already move value types for example within an 
> array just by plain moving the data of the value around. With a little 
> new keyword 'mov' or 'move' it would also be possible to move value 
> types into and out of functions, something like this:
> 
> mov Range findNext(mov Range r)
> {
>    //do stuff here
> }
> 
> With something like this it would not be neccessary to copy the range 
> twice during the call of this function, the compiler could just plain 
> copy the data and reinitialize the origin in case of the argument.
> In case of the return value to only copying would be neccessary as the 
> data goes out of scope anyway.

If Range is a Rvalue, it will be moved, not copied.
It it's a Lvalue, your operation is dangerous, and does not bring you 
much more than using ref (it may be faster to copy the range than to 
take the reference, but that's an optimiser issue).

auto ref seems to be the solution.

> I for example have a range that iterates over a octree and thus needs to 
> internally track which nodes it already visited and which ones are still 
> left. This is done with a stack container. That needs to be copied 
> everytime the range is copied, which causes quite some overhead.

I would share the tracking data between several instance of the range, 
making bitwise copy suitable. Tracking data would be duplicated only on 
call to save or opSlice(). You'd hit the issue of foreach not calling 
save when it should, but opSlice would solve this, and you could still 
overload opApply if you want to be sure.

-- 
Christophe


More information about the Digitalmars-d mailing list