• Bane <branimir.milosavljevic gmail.com> Feb 23 2010
• Rainer Schuetze <r.sagitario gmx.de> Feb 23 2010
• Walter Bright <newshound1 digitalmars.com> Feb 24 2010

Bane <branimir.milosavljevic gmail.com> writes:

A nasty typo, should be "...GC will be in dll too so people..."

 Just to get it righ: this means GC will be in dl tool so people that complain
about exe size and gc bloat will be happy about it?

Rainer Schuetze <r.sagitario gmx.de> writes:

Yes, GC is the main issue, as you want to pass gc-collected objects 
across dll boundaries. I'd say the size of the executables is just a 
secondary issue, though it would also benefit.

Bane wrote:
 A nasty typo, should be "...GC will be in dll too so people..."
 
 Just to get it righ: this means GC will be in dl tool so people that complain
about exe size and gc bloat will be happy about it?

Walter Bright <newshound1 digitalmars.com> writes:

Rainer Schuetze wrote:
 Yes, GC is the main issue, as you want to pass gc-collected objects 
 across dll boundaries. I'd say the size of the executables is just a 
 secondary issue, though it would also benefit.


The GC itself doesn't have to be in a dll for this to work. The library 
is already set up to hand off the GC. What it doesn't do at the moment 
is hand off the thread management.