On 3/3/15 9:40 AM, "Marc =?UTF-8?B?U2Now7x0eiI=?= <[email protected]>" wrote:
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.
No, the cool thing about freelists is they use free memory to chain
things together.
Somebody please write the code already. With no code we sit forever on
our testes speculating.
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.
Yes, that's exactly right, thanks for putting it so clearly.
Andrei
