aa.remove in a destructor

[Ellery Newcomer]

On 06/26/2012 12:41 PM, Steven Schveighoffer wrote:
>
> I want to red flag this code for another reason.
>
> You must *never* access GC-allocated references in a destructor, to do
> so will make the program crash randomly.

The docs should be so assertive (not that I read them or anything).

>
> The destructor is only for releasing non-GC resources, nothing else. You
> can't even *read* them reliably.
>
> The reason being, the AA you have referenced may have *already been
> collected* by the time your dtor is called.
>
> If you do manage to make an AA that is not GC allocated, you should be
> fine. You should be able to do this with dcollections, if you write a C
> malloc-based allocator (note to self, I should have this implemented...).
>
> -Steve

Yeah, I had a thought a while ago that std.container.RedBlackTree would 
work for me because I remember there being an allocate function in it 
somewhere when I was abusing it into shape for multi_index, but then the 
allocate function was private, and the class was final, and I don't 
think there was a deallocate function in the std.container version. I 
started to fork it but then changed my mind and built allocators into 
multi_index instead. It works great now, and probably doesn't leak too much.

Didn't look at dcollections, though.