On Tuesday, 3 March 2015 at 17:00:17 UTC, 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? Isn't that a big
price to pay?
All instances need to carry a pointer to refcount anyway, so the
freelist could just be stored next to the refcount. The idea of
creating that list, however, is more worrying, because it again
involves allocations. It can get arbitrarily long.
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?
As far as taking the address of an RcArray element, the type of
which element is not itself Rc'ed, it's a different problem.
The only thing I've been able to come up with is maybe to
create a wrapper type within RcArray for the individual
elements, and have that type do refcounting on the parent
instead of itself, if that's possible.
No, Andrei's proposed solution would take care of that. On
assignment to RCArray, if the refcount goes to zero, the old
array is put onto the cleanup list. But there can still be
borrowed references to it's elements. However, these can never
outlive the RCArray, therefore it's safe to destroy all of the
arrays in the cleanup list in the destructor.
