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