Article about problems & suggestions for D 2.0

[Benjamin Thaut]

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. Especially 
given the fact that D is a garbage collected language and could benefit 
a lot from features that make implementing a GC easier. 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.

-- 
Kind Regards
Benjamin Thaut