Writing a library

[Bill Baxter]

Jarrett Billingsley wrote:
> "Bill Baxter" <dnewsgroup at billbaxter.com> wrote in message 
> news:er58l2$i21$1 at digitalmars.com...
>> I'm not sure if the GC will work normally or not.  But I'm pretty sure 
>> you'll need to do something to startup and initialize the GC on the D 
>> side.  Check out WinMain in 
>> http://www.dsource.org/projects/minwin/browser/trunk/minwin/app.d at line 
>> 144.  In particular the calls to gc_init(), _minit(), _moduleCtor() and 
>> _moduleUnitTests().
> 
> The GC should work normally, but one thing you have to do is to make sure 
> you keep references to any GC memory (i.e. anything allocated with 'new' in 
> your D code) in the DLL.  One way of doing this for classes is to keep a 
> static list or AA of all instances of the class in the class:
> 
> class ExportedClass
> {
>     static bool[ExportedClass] instances;
> 
>     this()
>     {
>         ....
>         instances[this] = true;
>     }
> 
>     ~this()
>     {
>         instances.remove(this);
>     }
> }
> 
> This way, there is at least one reference to each class instance held in the 
> DLL, so that the instances won't get collected.  When the instances are 
> deleted, they are removed from the list. 

Ok, I wasn't sure about that.  But it makes sense now.  D memory 
allocated with 'new' is in some big D gc pool, and that's the only 
memory the GC scans for outstanding references.  Well, that and stuff on 
the D stack.  Anything in C land won't be noticed by the GC.  Makes sense.

--bb