Sounds reasonable iff we assume that ref counted stuff will never be shared across threads, which we seem to be assuming anyhow.
On Mon, Nov 1, 2010 at 12:21 AM, Andrei Alexandrescu <[email protected]>wrote: > Alright, then how do we solve refcounting of constant objects (see Michel > Fortin's question)? My solution involves casting away const and keeping > immutability information at runtime. Is that acceptable? > > Andrei > > > On 10/31/10 5:32 PM, Shin Fujishiro wrote: > >> I think cheap copy construction is must. Since any accesses to sealed >> range elements involve copy construction. >> >> I read older discussions and found that they mostly focused on swap >> and moveX. But the problem lies not only in the swap operation. It's >> everywhere and move doesn't help. >> >> Note that *every* access to an element of sealed range involves a copy >> construction. When sorting a sealed range of BigInts (Array!BigInt), >> even an innocent comparison creates two BigInt copies: >> >> if (!less(r[i], r[p])) // Creates two temporary copies. >> >> I think these copies can't be elided since original objects exist in a >> container at the same time. Still the compared elements could be moved >> out and then assigned back, but that's terribly awkward. >> >> We mostly don't want to move out elements - just want to read them. >> Sealed ranges are inherently copy intensive, so if you will put forward >> the concept, copy cost of elements must be assumed to be cheap IMO. >> >> >> Shin >> >> 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 >
_______________________________________________ phobos mailing list [email protected] http://lists.puremagic.com/mailman/listinfo/phobos
