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

[Masahiro Nakagawa]

On Mon, 01 Nov 2010 13:21:23 +0900, Andrei Alexandrescu  
<andrei at erdani.com> 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?

Your approach seems to be C++'s mutable. I am acceptable.

You said "There are several solutions possible" on digitalmars.D.
Can you show the example of other solutions?

"the compiler knowing about the idiom" means Python-like approach?
If so, I think such approach makes the compiler more complex :(


Masahiro

> 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<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
> _______________________________________________
> phobos mailing list
> phobos at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/phobos