Making sense of ranges

Jonathan M Davis jmdavisProg at gmx.com
Sat Mar 24 16:31:38 PDT 2012


On Saturday, March 24, 2012 23:07:01 Stewart Gordon wrote:
> Something else I'm finding puzzling is moveFront, moveAt and moveBack.  Is
> D trying to be C++11 or something?  Move semantics don't seem to me to be
> useful in a language with GC.

The GC doesn't have anything do with it. If you're dealing with objects on 
the GC heap, then they're either references or pointers and the situation is 
exactly the same as it is in C++ when using pointers except that the memory 
is freed by the GC when it's not used anymore rather than having to be 
manually freed. A move constructor doesn't do anything with a pointer in 
C++. It's when you have objects on the stack that hold stuff (including 
pointers) where they matter.

And since D has structs, a lot of stuff doesn't go on the heap anyway. It 
sits on the stack just like many C++ objects do. D deals with move semantics 
better than C++ does (see http://stackoverflow.com/questions/4200190/does-d-
have-something-akin-to-c0xs-move-semantics and 
http://stackoverflow.com/questions/6884996/questions-about-postblit-and-move-
semantics for more details), but if you allow arbitrarily complex postblit 
constructors, then there are some cases where you need to be able to specify 
that you're moving an object rather than copying it, and that's what the 
moveX functions are for. They allow a range to explicitly move a value 
rather than copy it.

Now, the moveX functions are probably going to go away at some point, 
because there's been a fair bit of discussion on assuming that postlbit 
constructors in D are O(1), which makes it so that you don't have to worry 
about moves. But they're there because of the possibility of arbitrarily 
complex postblit constructors.

- Jonathan M Davis


More information about the Digitalmars-d-learn mailing list