Ruling out arbitrary cost copy construction?

Bruno Medeiros brunodomedeiros+spam at com.gmail
Mon Nov 1 13:30:37 PDT 2010


On 31/10/2010 16:42, Andrei Alexandrescu wrote:
> On 10/31/10 8:04 AM, Michel Fortin wrote:
>> On 2010-10-30 23:56:24 -0400, Andrei Alexandrescu
>> <SeeWebsiteForEmail at erdani.org> said:
>>
>>> 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.
>>
>> A simple question: can a reference counter work with const and immutable?
>>
>> const(S) func(ref const(S) s) {
>> return s; // this should increment the reference counter, but can we
>> bypass const?
>> }
>>
>> Bypassing const/immutable could work, but if your data is immutable and
>> resides in read-only memory you'll get a crash.
>
> There are several solutions possible, some that require the compiler
> knowing about the idiom, and some relying on trusted code. One in the
> latter category is to create immutable objects with an unattainable
> reference count (e.g. size_t.max) and then incrementing the reference
> count only if it's not equal to that value. That adds one more test for
> code that copies const object, but I think it's acceptable.
>
> Andrei

Ehh? So here we would have logical const instead of strict const? Feels 
a bit like this could be an opening of Pandora's box...

-- 
Bruno Medeiros - Software Engineer


More information about the Digitalmars-d mailing list