[phobos] Fwd: Re: Ruling out arbitrary cost copy construction?

[Max Samukha]

 These notes on copy-constructible Qt types may be useful for the
discussion:

1. 1/5 (approx. 100 classes) of all classes in core, gui, network, webkit,
svg and opengl packages define public copy-constructors.

A half of those are in reference-counted COW types (approx. 50 classes). The
remaining 50 classes are reference-counted types without COW, types with
allocating copy-constructors and types with trivial non-allocating
constructors.

Most of the types with allocating copy-constructors I would probably
implemented as classes in D. Polymorphic types like QListWidgetItem that
provide the copy-constructor only for clone() reimplementation should
definitely be classes in D.

The conclusion I tend to draw is that expensive copy-constructors can be
avoided in most applications.

2. Reference counters are atomic using interlocked integer operations. There
have been a couple of complaints about performance [
http://www.gotw.ca/publications/optimizations.htm] but those complaints seem
ungrounded [
http://labs.qt.nokia.com/2006/10/16/atomic-reference-counting-is-it-worth-it-2
].

3. If a type exposes data by reference, proxy objects are used to avoid
unnecessary copying. For example, QString::operator[](int) returns an
instance of QСharRef, not QChar&. The shared data is copied only if the
QCharRef instance is modified.

On Sun, Oct 31, 2010 at 5:57 AM, Andrei Alexandrescu <andrei at erdani.com>wrote:

> I am highly interested in the opinion of Phobos contributors in the matter
> of copy construction (just posted the message below).
>
> Andrei
>
> -------- Original Message --------
> Subject: Re: Ruling out arbitrary cost copy construction?
> Date: Sat, 30 Oct 2010 22:56:24 -0500
> From: Andrei Alexandrescu <SeeWebsiteForEmail at erdani.org>
> Newsgroups: digitalmars.D
>
> 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
> _______________________________________________
> phobos mailing list
> phobos at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/phobos
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/phobos/attachments/20101103/c4c29638/attachment.html>