Hi, i'm a D newbie. I want to know how to compile an exe and a dll without garbage collector. I never add code related to the GC but when i compile my programs, Does the GC get included in my resulting compilation, making mi file bigger?

Thanx.

Heinz wrote:
> Hi, i'm a D newbie. I want to know how to compile an exe and a dll
> without garbage collector. I never add code related to the GC but
> when i compile my programs, Does the GC get included in my
> resulting compilation, making mi file bigger?
> 
> Thanx.

Currently, there's no way to do this since the GC is part of the standard library, which always gets linked in.

You might want to take a look at Ares, which seperates the standard library and GC, from what I remember.

	-- Daniel

Thanks Daniel for your answer.
OK, the GC get always linked, so i'll get extra bytes in my files but, does this
mean that the GC is active (run) when i open my application or the GC is just a
simple bunch of functions that are never called?

Heinz

Heinz wrote:
> Thanks Daniel for your answer.
> OK, the GC get always linked, so i'll get extra bytes in my files but, does this
> mean that the GC is active (run) when i open my application or the GC is just a
> simple bunch of functions that are never called?
> 
> Heinz

The GC is "run" in the sense that it is initialised when the application starts up.

However, what you have to understand is that the GC will not run a collection cycle UNLESS you attempt to 'new' some memory, and you've run out.  If you, for example, use C's malloc and free, then the GC won't ever be triggered.

(An exception to this is that when you quit, the GC runs a collection to clean up... I think.)

One other thing to keep in mind is that you can override the use of the GC on a per-class basis by overriding a class' 'new' member.  Lemme see if I can find the doc for it...

http://digitalmars.com/d/class.html#allocators

So, summary:

1. With stock DMD, the GC is always linked in.
2. The GC is always initialised on program startup.
3. The GC is used (by default) for the 'new' operator.
4. You can use a different allocator for 'new' on a per-class basis.
5. You can use any allocation scheme you like so long as you manually call it.
6. A collection is only run if you attempt to 'new' some memory, and there isn't enough free memory.

Hope that covers everything.

	-- Daniel

Daniel Keep wrote:
<snip>
> The GC is "run" in the sense that it is initialised when the application starts up.
> 
> However, what you have to understand is that the GC will not run a collection cycle UNLESS you attempt to 'new' some memory, and you've run out.

There are a number of ways to trigger allocation of memory on the heap:
- using associative arrays
- setting .length of an array
- calling .dup on an array
- concatenating arrays with ~ or ~=
- maybe others....

> If you, for example, use C's malloc and free, then the GC won't ever be triggered.
> 
> (An exception to this is that when you quit, the GC runs a collection to clean up... I think.)

It does seem to've changed since I last looked.

<snip>
> 1. With stock DMD, the GC is always linked in.
> 2. The GC is always initialised on program startup.
> 3. The GC is used (by default) for the 'new' operator.
> 4. You can use a different allocator for 'new' on a per-class basis.
> 5. You can use any allocation scheme you like so long as you manually call it.
> 6. A collection is only run if you attempt to 'new' some memory, and there isn't enough free memory.

I'd think it would make an effort to clean up so that it can reuse existing memory rather than claiming more and more from the OS.

Stewart.