aa.remove in a destructor

[Steven Schveighoffer]

On Sun, 24 Jun 2012 14:56:20 -0400, Ellery Newcomer  
<ellery-newcomer at utulsa.edu> wrote:

> On 06/24/2012 02:53 AM, Dmitry Olshansky wrote:
>>
>> I think no, as any with operation involving GC. For instance while you
>> are removing elements table may decide to rehash itself and that means
>> it may trigger allocation.
>>
>
> okay, it looks like my [inherited] code is using aa's to map D objects  
> to C wrapper objects and keep references to the D objects around. If the  
> builtin aa's aren't going to work, I'll need something else.
>
> Come to think of it, though, shouldn't the standard library provide an  
> aa implementation that doesn't rely on the gc?

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 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