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