On 8/30/11 12:45 AM, Benjamin Thaut wrote:
Am 30.08.2011 02:56, schrieb Andrei Alexandrescu:
On 8/29/11 4:36 PM, Walter Bright wrote:
On 8/29/2011 2:22 PM, Jonathan M Davis wrote:
Certainly, for the common case, adding move constructors is a needless
complication, and I'd _very_ leery of the ramifications of the
compiler not
being able to rely on a move having the bits stay absolutely identical
(and a
move constructor would make it possible for the struct's state to
change
completely instead of really being a move). It's not necessarily
completely
unreasonable, but you appear to have found what I would expect to be a
_very_
abnormal use-case.
Andrei and I have talked about adding move constructors, but I agree
with you that it really seems to be a tar pit we'd really like to avoid.
C++ has a lot of subtle problems caused by supporting this, not the
least of which is efficiency problems.
The language semantics make move construction unnecessary. Values are
moveable as bits through memory.
I think the article is a bit confused on this particular matter. Only
objects with value semantics are freely moveable, so they have no direct
interaction with the garbage collector. What they might want to do is to
hold a pointer/reference _inside_ of them and deregister that pointer
with the garbage collector with the destructor. Due to the indirection,
it doesn't matter where the object is in memory.
Andrei
I don't see implementing a GC as that of a abnormal use case.
Implementing a GC is an exceedingly rare privilege.
Especially
given the fact that D is a garbage collected language and could benefit
a lot from features that make implementing a GC easier.
I don't believe D should be in the business of adding features that make
implementing a GC easier. Such a task is extremely specialized; if the
language allows it, that's about enough.
In thise special
case the discussed struct would be a wrapper for every reference on the
stack, so the references can be tracked by the GC and changed if
neccessary. Adding a level of indirection to every reference would
greatly impact performance because it would most likely add yet another
cache miss when accessing a reference. I'm very well aware of D's
concept of structs. But sometimes this concept is very bad for
performance, that is what I wanted to point out. Adding a move
constructor which most of the structs won't even use, should be less of
a performance impact, then adding another level of indirection.
Clearly adding an extra level of indirection would be harmful, no two
ways about it. But essentially the object model is what it is: there are
value types that move, and there are reference types that don't. Deal
with it. If you need to implement a garbage collector, you can't do it
with move hooks because they're not provided. In a subtle way it's a
given, although I totally understand how this or that hook would make
your work easier. I don't find the complaint valid at all.
Andrei
