C++, D: Dinosaurs?

[Walter Bright]

dsimcha wrote:
> 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.

Modern C++ practices (as best as I can tell) make extensive use of 
ref-counting memory management, i.e. shared_ptr<>. This requires TWO 
allocations for each use, not just one. The second allocation is for the 
reference counting management.

Next, every time you copy a pointer (like pass it to a function, return 
it, etc.) you have to increment, then decrement, the reference count. If 
you've got multithreading on, this requires a mutex or the usual memory 
syncing primitives which are 100x slower than regular memory access.

You can escape the inc/dec overhead by converting the shared ptr to a 
regular pointer, but then you lose all the safety guarantees.