Ruling out arbitrary cost copy construction?

Bruno Medeiros brunodomedeiros+spam at com.gmail
Mon Nov 1 13:20:08 PDT 2010


On 31/10/2010 03:56, Andrei Alexandrescu wrote:
> On 10/30/2010 09:40 PM, Michel Fortin wrote:
>> On 2010-10-30 20:49:38 -0400, Andrei Alexandrescu
>> <SeeWebsiteForEmail at erdani.org> said:
>>
>>> On 10/30/10 2:24 CDT, Don wrote:
>>>> At the moment, I think it's impossible.
>>>> Has anyone succesfully implemented refcounting in D? As long as bug
>>>> 3516
>>>> (Destructor not called on temporaries) remains open, it doesn't seem to
>>>> be possible.
>>>> Is that the only blocker, or are there others?
>>>
>>> I managed to define and use RefCounted in Phobos. File also uses
>>> hand-made reference counting. I think RefCounted is a pretty good
>>> abstraction (unless it hits the bug you mentioned.)
>>
>> I like the idea of RefCounted as a way to automatically make things
>> reference counted.
>
> Unfortunately it's only a semi-automated mechanism.
>
>> But like File and many similar ref-counted structs, it has this race
>> condition (bug 4624) when stored inside the GC heap. Currently, most of
>> Phobos's ref-counted structs are race-free only when they reside on the
>> stack or if your program has only one thread (because the GC doesn't
>> spawn threads if I'm correct).
>>
>> It's a little sad that the language doesn't prevent races in destructors
>> (bug 4621).
>
> I hope we're able to solve these implementation issues that can be seen
> as independent from the decision at hand.
>
> Walter and I discussed the matter again today and we're on the brink of
> deciding that cheap copy construction is to be assumed. This simplifies
> the language and the library a great deal, and makes it perfectly good
> for 95% of the cases. For a minority of types, code would need to go
> through extra hoops (e.g. COW, refcounting) to be compliant.
>
> I'm looking for more feedback from the larger D community. This is a
> very important decision that marks one of the largest departures from
> the C++ style. Taking the wrong turn here could alienate many
> programmers coming from C++.
>
> So, everybody - this is really the time to speak up or forever be silent.
>
>
> Andrei

I would also go for "2. Constant-cost copy construction", but I can't 
really make a case for it. I can only state that it seems to me that the 
benefits in library simplification (both in implementation and API) 
would be far more valuable than the drawbacks ("Makes value types 
difficult to define").

It should be considered that those 5% types (large value types) will not 
strictly need to have a refcounting+COW support to be usable in 
containers and algorithms: just store pointers-to-the-value-type in the 
container, instead of using the value type directly. (Basicly, use them 
as reference types). So it's not the end of the world for some value 
type if it doesn't implement refcounting+COW.

-- 
Bruno Medeiros - Software Engineer


More information about the Digitalmars-d mailing list