On Sun, 02 Jan 2011 21:57:50 +0200, Walter Bright
<newshou...@digitalmars.com> wrote:
Sure, but D has *optional* gc. If you want to, you can use D as simply a
"better C" and it will compile to the same code as C does.
The usual comeback to that is that Phobos depends on the GC, so a great
part of the standard library was unusable without memory leaks. I think
this is an interesting problem, and solving it could both prove that D
*is* practically usable for nontrivial tasks without a GC, and provide a
solution for those who can't or don't want to use a GC (you may have
noticed how many upvotes the stackoverflow comment about people just not
wanting to use a GC got).
How much of D can you really use without Phobos? I imagine there'd be no
problem in using it as a better C, but there isn't much appeal to that,
compared to C++/STL/Boost. A practical No-GC D solution would probably
have to include a standard library that works without a GC.
Some ideas:
* A while ago, it was suggested that there be a version(NO_GC) or
something like that, and the standard library could be modified to work
differently depending on that version flag. It's probably not practically
possible, though, because some functions would not make sense in a GC-less
context (lack of GC would require changing their signature/documentation),
and the code would quickly become a jungle.
* Forking Phobos into a new standard library based on STL-like
RAII/refcount constructs (std::string, std::vector) instead of built-in
arrays, etc.
** The biggest problem with the above idea is that we're back to typing
long type names instead of having the luxury of built-in dynamic
arrays/AAs. There could be a language mode (controlled by a compiler
switch) which maps the syntax for built-in arrays/AAs to RAII/refcounting
library types.
--
Best regards,
Vladimir mailto:vladi...@thecybershadow.net
