<style type="text/css">p { margin-bottom: 0.08in; }</style>These notes on copy-constructible Qt types may be useful for the discussion:<br><br>1. 1/5 (approx. 100 classes) of all classes in core, gui, network, webkit, svg and opengl packages define public copy-constructors.<br>
<br>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.<br>
<br>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.<br>
<br>The conclusion I tend to draw is that expensive copy-constructors can be avoided in most applications.<br><br>2. Reference counters are atomic using interlocked integer operations. There have been a couple of complaints about performance [<a href="http://www.gotw.ca/publications/optimizations.htm">http://www.gotw.ca/publications/optimizations.htm</a>] but those complaints seem ungrounded [<a href="http://labs.qt.nokia.com/2006/10/16/atomic-reference-counting-is-it-worth-it-2">http://labs.qt.nokia.com/2006/10/16/atomic-reference-counting-is-it-worth-it-2</a>].<br>
<br>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.<br>
<br><div class="gmail_quote">On Sun, Oct 31, 2010 at 5:57 AM, Andrei Alexandrescu <span dir="ltr"><<a href="mailto:andrei@erdani.com">andrei@erdani.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
I am highly interested in the opinion of Phobos contributors in the matter of copy construction (just posted the message below).<br>
<br>
Andrei<br>
<br>
-------- Original Message --------<br>
Subject: Re: Ruling out arbitrary cost copy construction?<br>
Date: Sat, 30 Oct 2010 22:56:24 -0500<br>
From: Andrei Alexandrescu <<a href="mailto:SeeWebsiteForEmail@erdani.org" target="_blank">SeeWebsiteForEmail@erdani.org</a>><br>
Newsgroups: digitalmars.D<br>
<br>
On 10/30/2010 09:40 PM, Michel Fortin wrote:<br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
On 2010-10-30 20:49:38 -0400, Andrei Alexandrescu<br>
<<a href="mailto:SeeWebsiteForEmail@erdani.org" target="_blank">SeeWebsiteForEmail@erdani.org</a>> said:<br>
<br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
On 10/30/10 2:24 CDT, Don wrote:<br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
At the moment, I think it's impossible.<br>
Has anyone succesfully implemented refcounting in D? As long as bug 3516<br>
(Destructor not called on temporaries) remains open, it doesn't seem to<br>
be possible.<br>
Is that the only blocker, or are there others?<br>
</blockquote>
<br>
I managed to define and use RefCounted in Phobos. File also uses<br>
hand-made reference counting. I think RefCounted is a pretty good<br>
abstraction (unless it hits the bug you mentioned.)<br>
</blockquote>
<br>
I like the idea of RefCounted as a way to automatically make things<br>
reference counted.<br>
</blockquote>
<br>
Unfortunately it's only a semi-automated mechanism.<br>
<br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
But like File and many similar ref-counted structs, it has this race<br>
condition (bug 4624) when stored inside the GC heap. Currently, most of<br>
Phobos's ref-counted structs are race-free only when they reside on the<br>
stack or if your program has only one thread (because the GC doesn't<br>
spawn threads if I'm correct).<br>
<br>
It's a little sad that the language doesn't prevent races in destructors<br>
(bug 4621).<br>
</blockquote>
<br>
I hope we're able to solve these implementation issues that can be seen<br>
as independent from the decision at hand.<br>
<br>
Walter and I discussed the matter again today and we're on the brink of<br>
deciding that cheap copy construction is to be assumed. This simplifies<br>
the language and the library a great deal, and makes it perfectly good<br>
for 95% of the cases. For a minority of types, code would need to go<br>
through extra hoops (e.g. COW, refcounting) to be compliant.<br>
<br>
I'm looking for more feedback from the larger D community. This is a<br>
very important decision that marks one of the largest departures from<br>
the C++ style. Taking the wrong turn here could alienate many<br>
programmers coming from C++.<br>
<br>
So, everybody - this is really the time to speak up or forever be silent.<br>
<br>
<br>
Andrei<br>
_______________________________________________<br>
phobos mailing list<br>
<a href="mailto:phobos@puremagic.com" target="_blank">phobos@puremagic.com</a><br>
<a href="http://lists.puremagic.com/mailman/listinfo/phobos" target="_blank">http://lists.puremagic.com/mailman/listinfo/phobos</a><br>
</blockquote></div><br>