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.
