www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - DLL?

reply "Lloyd Dupont" <ld NewsAccount.galador.net> writes:
what about having phobos shipped (optionaly) as a DLL?
that would solve all (GC) headache when sharing D objects between D DLLs and 
Exe, no?
Oct 10 2004
parent reply kinghajj <kinghajj_member pathlink.com> writes:
In article <ckd2pv$j9r$1 digitaldaemon.com>, Lloyd Dupont says...

what about having phobos shipped (optionaly) as a DLL?
that would solve all (GC) headache when sharing D objects between D DLLs and 
Exe, no?


I don't think that Phobos can be made into a DLL yet, though I would LOVE for
that to be done. That would greatly reduce the size of executables.
Oct 11 2004
parent reply pragma <pragma_member pathlink.com> writes:
In article <ckfdq6$2i7a$1 digitaldaemon.com>, kinghajj says...

In article <ckd2pv$j9r$1 digitaldaemon.com>, Lloyd Dupont says...

what about having phobos shipped (optionaly) as a DLL?
that would solve all (GC) headache when sharing D objects between D DLLs and 
Exe, no?


I don't think that Phobos can be made into a DLL yet, though I would LOVE for
that to be done. That would greatly reduce the size of executables.


Its been brought up before.  At the very least, having the option to leave the
GC out of compilation or place it in a separate library for linking would do
half of this job for us.  That way, one could have only the GC in a given
library.

Another thing: its important to take into account the consequences for hooking a
GC from multiple independent libraries and applications.  I for one wouldn't
want *every* d-based application to use the same exact GC instance.  For reasons
of performance and security you'd want to at least have the option to compile it
in or opt for your own version.

If I may be frank: what we need is a GC that is easier to remove from phobos
altogether, so that it may be *optionally* compiled in.

Eric Anderton -- at -- yahoo
Oct 12 2004
parent reply Benjamin Herr <ben 0x539.de> writes:
pragma wrote:

 Another thing: its important to take into account the consequences for hooking
a
 GC from multiple independent libraries and applications.  I for one wouldn't
 want *every* d-based application to use the same exact GC instance.  For
reasons
 of performance and security you'd want to at least have the option to compile
it
 in or opt for your own version.


I thought they would only be running from the same code and not using 
the same instance? That would be a GC daemon and kind of tricky to 
implement, I assume.

-ben
Oct 12 2004
parent pragma <pragma_member pathlink.com> writes:
In article <ckgot3$ocl$1 digitaldaemon.com>, Benjamin Herr says...

pragma wrote:

 Another thing: its important to take into account the consequences for hooking
a
 GC from multiple independent libraries and applications.  I for one wouldn't
 want *every* d-based application to use the same exact GC instance.  For
reasons
 of performance and security you'd want to at least have the option to compile
it
 in or opt for your own version.


I thought they would only be running from the same code and not using 
the same instance? That would be a GC daemon and kind of tricky to 
implement, I assume.


I'd have to assume as well, since I've had only limited sucess trying to
surgically remove the collector from phobos.

It was my understanding that sharing a GC instance was the way forward, since

upper-hand over D.

There are numerous advantages to having at least all the same dlls within a
process using the same GC instance.  At the very least, you have a lot less work
to do in order to safeguard against premature collection, or loosing data when
you unload a library.

Offhand, I can't think of any advantage to having multiple /processes/ use the
same GC (using your daemon idea), but I'm sure something might benefit from such
an exotic model.  Maybe IPC could be enhanced in this fashion?

Eric Anderton -- at -- yahoo
Oct 12 2004