OSNews article about C++09 degenerates into C++ vs. D discussion

[Mike Capp]

John Reimer wrote:

> Avoid new/delete, dynamic arrays, array slice
> operations, and array concatenation.  I think
> that's it...

Also associative arrays. I'm not convinced, though, that slices require GC. I'd
expect GC-less slicing to be safe so long as the programmer ensured that the
lifetime of the whole array exceeded that of the slice. In many cases that's
trivial to do.

I don't like the fact that the same piece of code that initializes a stack array
in C will create a dynamic array in D. Porting accident waiting to happen.

> What I find strange is that some C++ users [...]
> then digress into a discussion on how they can
> improve on C++ default memory management by
> implementing a /custom/ solution in there own C++
> programs.  How is this different than in D?

Dunno; I'd never argue otherwise. I've never found a need to implement a custom
allocator in C++ (especially STL allocators, which turned out to be a complete
waste of paper).

> D makes it even easier to do this.  These guys
> likely would be serious D wizards if they ever
> tried it out.

Yeah. Similarly, I think Walter's too pessimistic when he doubts that the "career"
C++ people will ever switch.

C++ has been a peculiar language lately; for all practical intents and purposes it
forked a few years back into two diverging dialects. One is fairly conservative
and is used to write production code that needs to maintained by people not named
Andrei. The other is a cloud-cuckoo-land research language used to see what can be
done with template metaprogramming.

The people drawn to the latter dialect, from Alexandrescu all the way back to
Stepanov, enjoy pushing a language's features beyond what the original designer
anticipated. Given D's different and richer feature set, I'd be amazed if they
didn't have fun with it.

> It's no problem avoiding the GC,

No? Hypothetical: your boss dumps a million lines of D code in your lap and says,
"Verify that this avoids the GC in all possible circumstances". What do you do?
What do you grep for? What tests do you run?

That's not rhetorical; I'm not saying there isn't an answer. I just don't see what
it is.

> It appears my "unfair" statement is slowly being
> dragged into broader realms. I'm not so sure it's
> maintaining its original application anymore.

Fair enough; I don't mean to drag you kicking and screaming out of context.

> A standard non-gc based library is likely not
> going to meet with massive approval from those
> already in the community

I should clarify. I'm not proposing that the entire standard library should have a
GC-less implementation, just that it should be as useful as possible without
introducing GC usage when the user is trying to avoid it.

Crude analogy: imagine everything in Phobos being wrapped in a version(GC) block.
Phobos is normally built with -version=GC, so no change for GC users. GC-less
users use Phobos built without GC, so none of the library is available, which is
where they were anyway.

Now, a GC-less user feels the need for std.foo.bar(). They look at the source, and
find that std.foo.bar() won't ever use GC because all it does is add two ints, so
they take it out of the version(GC) block and can now use it. Or they write a less
efficient but GC-less implementation in a version(NOGC) block. Either way, they
get what they want without affecting GC users. It's incremental, and the work is
done by the people (if any) who care.

cheers
Mike