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 <[email protected]>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 <[email protected]> > Newsgroups: digitalmars.D > > On 10/30/2010 09:40 PM, Michel Fortin wrote: > >> On 2010-10-30 20:49:38 -0400, Andrei Alexandrescu >> <[email protected]> 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 > [email protected] > http://lists.puremagic.com/mailman/listinfo/phobos >
_______________________________________________ phobos mailing list [email protected] http://lists.puremagic.com/mailman/listinfo/phobos
