Sounds reasonable iff we assume that ref counted stuff will never be shared across threads, which we seem to be assuming anyhow.<br><br><div class="gmail_quote">On Mon, Nov 1, 2010 at 12:21 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;">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?<br>
<font color="#888888">
<br>
Andrei</font><div><div></div><div class="h5"><br>
<br>
On 10/31/10 5:32 PM, Shin Fujishiro 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 think cheap copy construction is must. Since any accesses to sealed<br>
range elements involve copy construction.<br>
<br>
I read older discussions and found that they mostly focused on swap<br>
and moveX. But the problem lies not only in the swap operation. It's<br>
everywhere and move doesn't help.<br>
<br>
Note that *every* access to an element of sealed range involves a copy<br>
construction. When sorting a sealed range of BigInts (Array!BigInt),<br>
even an innocent comparison creates two BigInt copies:<br>
<br>
if (!less(r[i], r[p])) // Creates two temporary copies.<br>
<br>
I think these copies can't be elided since original objects exist in a<br>
container at the same time. Still the compared elements could be moved<br>
out and then assigned back, but that's terribly awkward.<br>
<br>
We mostly don't want to move out elements - just want to read them.<br>
Sealed ranges are inherently copy intensive, so if you will put forward<br>
the concept, copy cost of elements must be assumed to be cheap IMO.<br>
<br>
<br>
Shin<br>
<br>
Andrei Alexandrescu<<a href="mailto:andrei@erdani.com" target="_blank">andrei@erdani.com</a>> 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<br>
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>
</blockquote>
_______________________________________________<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>
_______________________________________________<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>
</div></div></blockquote></div><br>