D without a GC (Was: Advocacy (Was: Who here actually uses D?))
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, Vladimirmailto:vladi...@thecybershadow.net
Re: D without a GC (Was: Advocacy (Was: Who here actually uses D?))
Vladimir Panteleev wrote: 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, I don't agree there's not much appeal to that. D has quite a bit that makes C-style code much easier and more robust, such as the module system. C doesn't even have thread local storage! compared to C++/STL/Boost. A practical No-GC D solution would probably have to include a standard library that works without a GC. D can use the minimal library used by C in kernel dev.
Re: D without a GC (Was: Advocacy (Was: Who here actually uses D?))
On Mon, 03 Jan 2011 21:41:37 +0200, Walter Bright newshou...@digitalmars.com wrote: Vladimir Panteleev wrote: 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, I don't agree there's not much appeal to that. D has quite a bit that makes C-style code much easier and more robust, such as the module system. C doesn't even have thread local storage! You took my line out of context :) Of course D is better than C and can be used as a better C, but I was making the comparison to C++/STL/Boost. Well, it depends on which features you're after - if you're Linus Torvalds and hate abstractions, D minus Phobos would indeed be a better deal than C++/STL/Boost :) -- Best regards, Vladimirmailto:vladi...@thecybershadow.net
Re: D without a GC (Was: Advocacy (Was: Who here actually uses D?))
Vladimir Panteleev wrote: You took my line out of context :) Of course D is better than C and can be used as a better C, but I was making the comparison to C++/STL/Boost. Well, it depends on which features you're after - if you're Linus Torvalds and hate abstractions, D minus Phobos would indeed be a better deal than C++/STL/Boost :) I should also point out that anyone who has the chops to build a kernel can certainly build a customized D runtime.
