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

[Sean Kelly]

Mike Capp wrote:
> 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).

STL allocators can be useful for adapting the containers to work with 
shared memory.  And I created a debug allocator I use from time to time. 
  But the complexity allocators add to container implementation is 
significant, for arguably little return.

>> 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.

I suppose it depends on how you define "career."  If it's simply that a 
person uses the language because it is the best fit for their particular 
problem domain and they are skilled at using it, then I think such a 
user would consider D (I certainly have).  But if you define it as 
someone who is clinging to their (possibly limited) knowledge of C++ and 
is not interested in learning new skills then probably not.  Frankly, I 
think the greatest obstacle D will have is gaining traction in existing 
projects.  With a decade or two of legacy C++ code to support, adopting 
to D is simply not feasible.  Training is another issue.  A small 
development shop could switch languages relatively easily, but things 
are much more difficult if a build team, QA, various levels of 
programmers, etc, all need to learn a new language or tool set.  At that 
point the decision has more to do with short-term cost than anything.

> 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.

LOL.  Pretty much.  Professionally, it's uncommon that I'll meet C++ 
programmers that have much experience with STL containers, let alone 
knowledge of template metaprogramming.  Even techniques that I consider 
commonplace, like RAII, seem to be unknown to many/most C++ programmers. 
  I think the reality is that most firms still write C++ code as if it 
were 1996, not 2006.

>> 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?

I'd probably begin by hooking the GC collection routine and dumping data 
on what was being cleaned up non-deterministically.  This should at 
least point out specific types of objects which may need to be managed 
some other way.  But it still leaves bits of dynamic arrays discarded by 
resizes, AA segments, etc, to fall through the cracks.  A more complete 
solution would be to hook both allocation and collection and generate 
reports, or rely on a tool like Purify.  Probably pretty slow work in 
most cases.

> 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.

This is really almost situational.  Personally, I try to balance 
elegance and intended usage with optional destination buffer parameters 
and such.  In the algorithm code I've written, for example, the only 
routines that allocate are pushHeap, unionOf (set union), and 
intersectionOf (set intersection).  It would be possible to allow for 
optional destination buffers for the set operations, but with optional 
comparison predicates already in place, I'm faced with deciding whether 
to put the buffer argument before or after the predicate... and neither 
is ideal.  I guess a bunch of overloads could solve the problem, but 
what a mess.


Sean