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