Well, I've done it.
I've stripped out the garbage collector from phobos and used malloc and free
calls to get the job done! Destructors are now called when the object is
explicity deleted with the delete keyword, instead of thru the garbage
collector. This should help D prove useful in systems programming as well as
embedded programming. However, if you really wanted to do embedded programming
with D, you'd rewrite portions of phobos yourself ;).
I did this because I want to use D to write games. Writing games usually
involves using DLLs, and it's nice not to worry about the garbage collector
ruining things in that department. Also, its nice to keep track of your memory.
IMHO, I'd rather take the penalty of potential memory-freeing bugs so I can use
DLLs.
Some code is in place to keep track of all allocated memory and will free that
memory on program termination (when gc_term() is called), but that's only
enabled under version (KEEPTRACK). This might be being a bit paranoid, but
really helps to debug memory leaks!
This code compiles on both Linux and Windows (I tested it!).
But alas, I'll have to wait a day or two to post the patch online. Sorry! I'll
post both a ZIP file of the modified phobos source files, binary copies of the
windows and linux libraries, and a patch file in a few days time.
Regards,
James Dunne

Well, I've done it.
I've stripped out the garbage collector from phobos and used malloc and free
calls to get the job done! Destructors are now called when the object is
explicity deleted with the delete keyword, instead of thru the garbage
collector. This should help D prove useful in systems programming as well as
embedded programming. However, if you really wanted to do embedded programming
with D, you'd rewrite portions of phobos yourself ;).
I did this because I want to use D to write games. Writing games usually
involves using DLLs, and it's nice not to worry about the garbage collector
ruining things in that department. Also, its nice to keep track of your
memory.
IMHO, I'd rather take the penalty of potential memory-freeing bugs so I can use
DLLs.
Some code is in place to keep track of all allocated memory and will free that
memory on program termination (when gc_term() is called), but that's only
enabled under version (KEEPTRACK). This might be being a bit paranoid, but
really helps to debug memory leaks!
This code compiles on both Linux and Windows (I tested it!).
But alas, I'll have to wait a day or two to post the patch online. Sorry!
I'll
post both a ZIP file of the modified phobos source files, binary copies of the
windows and linux libraries, and a patch file in a few days time.
Regards,
James Dunne

It would be great if there were two distributions of phobos available in
the standard dmd package, one phobos.lib (with gc) and one
phobos_ngc.lib (for no gc). Then the developer can decide which one to
link with for the project build process (perhaps using a version statement).
Great work, James. I just wish the idea would migrate into the actual
dmd distribution.
On the other hand:
The only potential problem with having gc and non-gc d projects is that
the programming style changes drastically between the two. Thus you
practically get 2 different d languages. What happens to dynamic
arrays? It could get messy if you have to manually new and delete those
for every little change.
Just some thoughts,
John

The only potential problem with having gc and non-gc d projects is that
the programming style changes drastically between the two. Thus you
practically get 2 different d languages. What happens to dynamic
arrays? It could get messy if you have to manually new and delete those
for every little change.

Wouldn't it be similar to calling std.gc.disable(),
without ever calling enable again as is the standard ?
For such small programs, the memory leaks would be
acceptable - and cleaned up upon program termination.
(assuming that the KEEPTRACK option is being used)
On the other hand, throwing in a few "delete" statements
in a regular (garbage collected) programs wouldn't really
hurt it ? - just the well-known bug potential of course.
Sometimes I've even done that in Java (mostly out of habit),
by explicitly setting the reference to null when done with it.
But having an *option* to compile without GC support would
sure make "Hello World" smaller. (and not require -lpthread?)
Looking forward to the patch!
--anders

Well, I've done it.
I've stripped out the garbage collector from phobos and used malloc and

free

calls to get the job done! Destructors are now called when the object is
explicity deleted with the delete keyword, instead of thru the garbage
collector. This should help D prove useful in systems programming as well

as

embedded programming. However, if you really wanted to do embedded

programming

with D, you'd rewrite portions of phobos yourself ;).
I did this because I want to use D to write games. Writing games usually
involves using DLLs, and it's nice not to worry about the garbage

collector

ruining things in that department. Also, its nice to keep track of your

memory.

IMHO, I'd rather take the penalty of potential memory-freeing bugs so I

can use

DLLs.
Some code is in place to keep track of all allocated memory and will free

that

memory on program termination (when gc_term() is called), but that's only
enabled under version (KEEPTRACK). This might be being a bit paranoid,

but

really helps to debug memory leaks!
This code compiles on both Linux and Windows (I tested it!).
But alas, I'll have to wait a day or two to post the patch online. Sorry!

I'll

post both a ZIP file of the modified phobos source files, binary copies of

the

windows and linux libraries, and a patch file in a few days time.
Regards,
James Dunne

Have you analyzed phobos for memory leaks, or are you going to only use
library routines that don't assume the GC will collect garbage? I'm thinking
of routines like std.string.toStringz which sometimes makes a copy and
sometimes doesn't (and sometimes returns a constant string that even isn't
dynamically allocated) so the caller has to be very careful about freeing
the result. That seems like a huge pain to do.
-Ben

I've looked at all those problems in phobos, and yeah, it can sure be a pain.
However, the KEEPTRACK versioned code should help in that department.
Dynamically resizing arrays is a little overkill since it always reallocates,
but better memory management (more complex) should be written to handle that
nicely and overallocate memory.
I haven't analyzed phobos at all for memory leaks, but I know there are a lot.
Switching to this mode of non-GC programming using a library made to take
advantage of the GC will have its disadvantages. Strings are the worst-case
scenario that I can see here.
Oh, and yes, removing the GC will remove the dependency on the pthreads library,
so that should lighten your executables a bit, unless you're using the
std.thread functions.
In article <crjjrs$27n7$1 digitaldaemon.com>, Ben Hinkle says...

Have you analyzed phobos for memory leaks, or are you going to only use
library routines that don't assume the GC will collect garbage? I'm thinking
of routines like std.string.toStringz which sometimes makes a copy and
sometimes doesn't (and sometimes returns a constant string that even isn't
dynamically allocated) so the caller has to be very careful about freeing
the result. That seems like a huge pain to do.
-Ben

But alas, I'll have to wait a day or two to post the patch online. Sorry! I'll
post both a ZIP file of the modified phobos source files, binary copies of the
windows and linux libraries, and a patch file in a few days time.