RCArray is unsafe
Zach the Mystic via Digitalmars-d
digitalmars-d at puremagic.com
Tue Mar 3 12:35:06 PST 2015
On Tuesday, 3 March 2015 at 18:48:36 UTC, Andrei Alexandrescu
> On 3/3/15 9:00 AM, Zach the Mystic wrote:
>> On Tuesday, 3 March 2015 at 16:31:07 UTC, Andrei Alexandrescu
>>>> I was dazzed, but I'm not anymore. I wrote my concern here:
>>> There's a misunderstanding here. The object being assigned
>>> keeps a
>>> trailing list of past values and defers their deallocation to
>>> destruction. -- Andrei
>> So you need an extra pointer per instance?
> Yah, or define your type to be single-assignment (probably an
> emerging idiom). You can massage the extra pointer with other
> data thus reducing its cost.
>> Isn't that a big price to
>> pay? Is the only problem we're still trying to solve aliasing
>> which is
>> not recognized as such and therefore doesn't bump the
>> refcounter like it
>> should? An extra pointer would be overkill for that. Isn't it
>> better to
>> just recognize the aliasing when it happens?
> It's all tradeoffs. This has runtime overhead.
Isn't allocating and collecting a freelist also overhead?
> A static analysis would have the challenges of being permissive
> enough, cheap enough, not add notational overhead, etc. etc.
It's certainly permissive: you can do anything, and compiler
wraps uncertain operations with add/release cycles automatically.
These are: passing a global as a mutable reference to an impure
function; aliasing the same variable in two parameters with
itself. The unoptimized lowerings would be:
auto tmp = myGlobal; // bump count
} // tmp destroyed, --count
auto tmp2 = c; // bump count
} // --count
The only addition is an optimization where the compiler elides
the assignments and calls the add/release cycles directly.
More information about the Digitalmars-d