Clarifcation on AA allocation

[pragma]

In article <e19b2t$5th$1 at digitaldaemon.com>, kris says...
>
>pragma wrote:
>> Is there any way to 'manually' allocate memory for an AA in D?
>> 
>> The problem that prompted me to ask this?  Well, I have a class that maintains a
>> set of HANDLES using an AA.  Ideally, I'd like to be able to free these using
>> the class' dtor(), but isn't there the possibility that the GC will eliminate
>> the AA's memory before the dtor() is even called?
>
>That's right. You cannot rely on any related GC-managed memory to be 
>intact when a dtor is invoked. As Sean noted, D "death tractors" are 
>akin to finalizers elsewhere.
>
>> 
>> I suppose I could instruct the GC to 'ignore' the AA via 'removeRange' for
>> safety reasons, but I'd like to know if anyone else has a more elegant solution?
>
>Or malloc() them into your own list, and use the AA simply as an 'alias' 
>of sorts?

Now *that* might just work.

>
>Are instances of this class intended to be long-lived? Singleton, perhaps?

Sadly no.  The suspect code is here:

http://www.dsource.org/projects/ddl/browser/trunk/ddl/omf/OMFBinary.d?rev=169

The OMFBinary class maintains a map of library names to HANDLEs for DLL's in
order to resolve IMPLIB style external references.  It works pretty well.  Since
the scope of use for any of these HANDLES is the same as the referencing binary,
they should logically be disposed of at the same time.

I suppose I could move the IMPLIB resolution and DLL loading out to a separate
Singleton class - that might help with a lot of these design issues.  After all
there's no big reason why it has to stay within the OMFBinary class itself, its
just more convienent that way.

You've given me much to ponder.  Thanks for the ideas. :)

- EricAnderton at yahoo