On 3/2/15 2:57 PM, Walter Bright wrote:
On 3/2/2015 1:09 PM, "Marc =?UTF-8?B?U2Now7x0eiI=?= <[email protected]>"
wrote:
"I have discovered a marvellous solution, but this post is too short
to describe
it."
Fortunately, Fermat (er, Andrei) was able to pass along his dazz idea to
me this afternoon, before he expired to something he had to attend to.
We were both in the dumps about this problem last night, but I think he
solved it.
His insight was that the deletion of the payload occurred before the end
of the lifetime of the RC object, and that this was the source of the
problem. If the deletion of the payload occurs during the destructor
call, rather than the postblit, then although the ref count of the
payload goes to zero, it doesn't actually get deleted.
I.e. the postblit manipulates the ref count, but does NOT do payload
deletions. The destructor checks the ref count, if it is zero, THEN it
does the payload deletion.
Pretty dazz idea, dontcha think? And DIP25 still stands unscathed :-)
Unless, of course, we missed something obvious.
And since an RCArray may undergo several assignments during its lifetime
(thus potentially needing to free several chunks of memory), the arrays
to be destroyed will be kept in a freelist-style structure. Destructor
walks the freelist and frees the chunks.
Andrei
