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
