On Sun, 24 Jun 2012 14:56:20 -0400, Ellery Newcomer
<ellery-newco...@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
