<mailto:pjmlp@progtools.org>>
Am 10.12.2011 21:35, schrieb Andrei Alexandrescu:
On 12/10/11 2:22 PM, maarten van damme wrote:
Just for fun I
wanted to create a program as little as possible,
compiled without
garbage collector/phobos/... and it turned out that
compiling without
garbage collector is pretty much impossible (memory
leaks all around the
place in druntime). dynamic linking for the d standard
library would be
a great new option for a dmd release in the future :).
Using D without GC is an interesting direction, and dynamic
linking
should be available relatively soon.
Andrei
As a long time beliver in systems programming languages with GC
support
(Modula-3, Oberon, Sing#, ...), I think allowing this in D is
the wrong direction.
Sure provinding APIs to control GC behavior makes sense, but not
turn it
off, we already have enough languages to do systems programming
without GC.
I was only trying it "for the fun of it", not to be used seriously.
D should always have it's GC support built-in and have some
functions to control it's behaviour (core.memory). But I think that
D, beeing a systems programming language, should also be able to be
used without GC. I don't mean phobos to be writtin without a GC in
mind but druntime should be compilable with something like a -nogc
flag that make it usable without GC.
There are a lot of users out there who think that a GC produces
terribly slow programs, big hangs while collecting,... (thank java
for that. Right now the java GC has been improved and it's extremely
good but the memory stays :p)
Letting them know that D can be run without GC can be a good point.
If they don't like it, they can turn it off.
That's got nothing to do with it. People who seriously NEED to be able
to use the language without the GC enabled are probably working on small
embedded systems with extremely limited resources. It's also possible
that various different resource types need to be allocated/located in
different places.
Also, In many cases, you need to able to have confidence in strict
deterministic allocation patterns. You can't do that with a GC enabled.
I'm all about having a GC in D, obviously, but I certainly couldn't
consider the language for universal adoption in many of my projects
without the option to control/disable it at times.
If I can't write some small programs with the GC completely disabled,
then I basically can't work on microprocessors. It's fair to give up the
standard library when working in this environment, but druntine, the
fundamental library, probably still needs to work. Infact, I'd
personally like it if it was designed in such a way that it never used
the GC under any circumstances. No library FORCED on me should restrict
my usage of the language in such a way.