Article about problems & suggestions for D 2.0

Andrei Alexandrescu SeeWebsiteForEmail at erdani.org
Mon Aug 29 17:56:49 PDT 2011


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


More information about the Digitalmars-d mailing list