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