Right now, what's the most important for the success and adoption of D?

Bruce Adams tortoise_74 at yeah.who.co.uk
Sat Sep 29 16:18:18 PDT 2007


Jarrett Billingsley Wrote:

> "Daniel Keep" <daniel.keep.lists at gmail.com> wrote in message 
> news:fdkb16$1duo$1 at digitalmars.com...
> 
> > Basically, there are two problems.  The first is that Windows uses DLLs.
> > DLLs cannot import symbols from the host they're being loaded into.
> > This means that a D DLL cannot get access to the host's garbage
> > collector, and must run its own.
> >
> > This is a *huge* problem because you now can't share memory between the
> > host and the DLL because the GC's are going to collect memory they can't
> > see.  If the DLL passes an array back to the host, that array could be
> > collected at *any moment* by the DLL's GC.
> 
> Actually, I think this was solved a while ago; basically you can set the GC 
> to use a different GC than the one defined in the DLL.  That is, you can 
> hook the DLL's GC into the host app.
> 
> But even if this is solved, there's a much more sinister problem with DLLs, 
> for the same reason (no linking to host symbols): typeinfo.  Basically, if 
> you have a library that defines class A, and your host app uses class A and 
> you make a DLL that uses class A, the class A in the host app is not the 
> same class A as in the DLL.  This breaks just about everything OOP.
> 
> >  2. We all start to chip in and get DDL back on its feet.
> >
> > Personally, I think 2 is the way to go :)
> 
> I totally agree.  Pragma, don't be too proud to ask for help :) 
> 
I don't get what the problem is. C++ must have had to solve the same problem long ago. Surely its just a matter of requiring libraries to exposes a particular interface for the runtime to hook into?
It seems like something too obvious to have been omitted from the D language specification.

Bruce.




More information about the Digitalmars-d mailing list