On Tuesday, 3 March 2015 at 18:48:36 UTC, Andrei Alexandrescu
wrote:
On 3/3/15 9:00 AM, Zach the Mystic wrote:
On Tuesday, 3 March 2015 at 16:31:07 UTC, Andrei Alexandrescu
wrote:
I was dazzed, but I'm not anymore. I wrote my concern here:
http://forum.dlang.org/post/[email protected]
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
impureFun(myGlobal);
} // tmp destroyed, --count
{
auto tmp2 = c; // bump count
fun(c, c);
} // --count
The only addition is an optimization where the compiler elides
the assignments and calls the add/release cycles directly.
