already has, as part of the language, Design by Contract and unit testing. The D Programming Language. These provide the robustness capabilities, but while having the power of a C++ like language.
Do any stray pointers to it just dangle, or does something null them out? Are references through them caught, or a quiet error?
There's no way to detect dangling pointers if you explicitly delete a gc'd object. So, be sure there aren't any if you're using delete explicitly, just as if you were doing free() in C.
If the GC finds the pointers later does it throw an error, ignore it, or end up doing something wrong?
what you do if you want RAII on objects you return from a function (auto can't be returned, or be an out parm, right?).
You'll need to use the delete on those.
What is the D equivalent to a shared_ptr of iostream (or a auto_ptr of the same)?
Not necessary in D, use the gc to manage routine memory.
What would a library use to hold objects that might be heavy weight objects (network sockets maybe, or 3D textures stored on a graphics card)? Is there some idiom for it?
Depends on the situation, but one idiom that works well is to create an RAII object that holds the resource, and create that in the user code, not the library.
Oh, and is there a weak reference for use in caches or the like? (yeah, ok, so it always looks so good in manuals, and I've never gotten around to using them for caches, but I have used it in a few places for things like "call the timeout function in 20 seconds if this request is still alive")
One of the things that makes HotSpot kewl is that it moves around memory as it does collection; as a result long-lived objects get compacted together, taking advantage of cache loads. This can't be easily done in GC if it's not allowed to fool with your pointers safely.
This is very possible to do with D, and the only reason it isn't doing it right now is I haven't spent the time on the GC to make that happen.
Its all a conspiracy by computer manufacturers.
If that's true, they haven't let me in on the conspiracy, and none of them have offered me any money to make D slow:-)
While the odds against D have been daunting, it is well on the exponential growth/adoption curve. The D newsgroup (news.digitalmars.com) has over 25,000 postings in it, and the downloads of the language increase substantially month by month. There's now a gnu version of the compiler, and a growing list of third party libraries and projects for it (see these, for example).
The real question is, when are you going to write a book on D?:-)
It turns out that D's nested functions handle quite nicely the macro use of factoring out performance critical redundant code in a function. They are subject to inlining by the compiler, and so produce every bit as good code as a macro, without all the problems macros have (like no scoping, no declarations, side effects of parameters, etc.).
already has, as part of the language, Design by Contract and unit testing. The D Programming Language. These provide the robustness capabilities, but while having the power of a C++ like language.
Yes, a gc can be forced.
There's no way to detect dangling pointers if you explicitly delete a gc'd object. So, be sure there aren't any if you're using delete explicitly, just as if you were doing free() in C.
If the GC finds the pointers later does it throw an error, ignore it, or end up doing something wrong?
Ignore it.
You'll need to use the delete on those.
What is the D equivalent to a shared_ptr of iostream (or a auto_ptr of the same)?
Not necessary in D, use the gc to manage routine memory.
What would a library use to hold objects that might be heavy weight objects (network sockets maybe, or 3D textures stored on a graphics card)? Is there some idiom for it?
Depends on the situation, but one idiom that works well is to create an RAII object that holds the resource, and create that in the user code, not the library.
Oh, and is there a weak reference for use in caches or the like? (yeah, ok, so it always looks so good in manuals, and I've never gotten around to using them for caches, but I have used it in a few places for things like "call the timeout function in 20 seconds if this request is still alive")
There's currently no support for weak references.
not a translator. It doesn't emit C code. It emits compiled object files.
Googling for "D Programming Language" or "Programming Language D" works rather well.
This is very possible to do with D, and the only reason it isn't doing it right now is I haven't spent the time on the GC to make that happen.
Its all a conspiracy by computer manufacturers. If that's true, they haven't let me in on the conspiracy, and none of them have offered me any money to make D slow :-)
The real question is, when are you going to write a book on D? :-)
David Friedman has integrated the D frontend with GCC.
It turns out that D's nested functions handle quite nicely the macro use of factoring out performance critical redundant code in a function. They are subject to inlining by the compiler, and so produce every bit as good code as a macro, without all the problems macros have (like no scoping, no declarations, side effects of parameters, etc.).
see templates
D has this. One can specifically delete a GC-allocated object, and the GC will delete it immediately without running a collection pass.
I find that googling on "D programming language" or "programming language D" works well.