C++, D: Dinosaurs?

[dsimcha]

== Quote from Daniel de Kok (daniel at nowhere.nospam)'s article
> On Fri, 14 Nov 2008 22:48:41 -0600, Tony wrote:
> > breakers for some (a lot?) of software. That's why I think GC should be
> > an opt-in rather than an opt-out choice. That's a key characteristic of
> > C++: opt-in. And I really, really like that level of creative freedom.
> That's not necessarily good. There are now multiple commonly-used methods
> for pointing to instances in C++: plain pointers, references, and smart
> pointers, all with different usage and semantics. It's a burden for
> library writers and library users. An opt-in GC only makes the burden
> heavier.
> In contrast, most GC-ed languages make life simpler not requiring a
> plethora of alternate management/lifetime schemes.
> Take care,
> Daniel

Agreed.  Also, whether or not GC is the default in a language deeply affects the
de facto standard way of doing things.  For example, in C++, you don't have nice
slice syntax in STL because STL is designed for use with manual memory management.
 Also, from what I've seen and heard, you tend to lose a lot of the theoretical
efficiency of manual memory management when you replace it with ref counting
(read:  poor man's GC), or lots of copying to make every object have a clear
owner.  I translated a small but computationally intensive machine learning
program from C++ to D a few months ago, and the D version was drastically faster
because it avoided lots of excess copying.  Granted, the C++ version *could* have
been more optimized, but in the real world, people don't have forever to optimize
all this stuff away.

Another interesting thing about D that I don't think people give enough notice to
is how cleanly you can mix manual and automatic memory management to get the best
of both.  GC is fast (compared to manual memory management) when you have large
amounts of small objects with non-trivial lifetimes.  It is slow when you have a
few large objects with trivial lifetimes.  The way I usually write my code, which
is generally number crunching type stuff that can require lots of scratch space,
is to use GC for all the small objects and objects where the lifetime is
non-trivial, and free things like scratch arrays that can be large and are only
used within one function manually.