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?

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.

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

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

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 its one area where C# and Java (and virtually all soft-coded languages) have the 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