
C++ and Beyond 2011: Herb Sutter - Why C++? (video) - sosuke
http://channel9.msdn.com/posts/C-and-Beyond-2011-Herb-Sutter-Why-C
======
splicer
So long as I'm not forced to switch from C to C++ at work, I'm fine with C++
getting popular.

~~~
georgemcbay
Are you me, but posting from 1996?

~~~
splicer
Yes.

------
smegel
I have to say, I have heard surprisingly little about C++11 since it was
finalized. Is it well supported yet? Are people starting to use it in anger?
Or did everyone move on to C# years ago I wonder...

~~~
codewright
C or C++ are still (depending on background) the systems languages of first-
resort for things like writing a database or an operating system. The
exception to the former is usually Java depending on ecosystem and the
programmers involved. (Cassandra, et al)

No-compromise performance still happens with C and C++. Secondarily Fortran
and Ada for their respective industries. I doubt that'll change anytime soon
as I'm not seeing any languages that are choosing the same priorities. Go
isn't a systems language by any measure or estimation in design or
implementation, and Rust is a type-safety-centric compromise that will likely
end up somewhere around Java in performance. I'm not seeing much indication
from the mailing list that safety-off all-go performance is a priority for the
Rust devs because they seemed to favor avoiding the quagmire of a large C++
codebase.

I think realistically a "clean start" of C++ with the best of C++11 and
earlier standards but removing a lot of the less worthwhile features would go
a long way. Won't happen though. A lot of people avoid those problems by just
writing C. Missing out on the cool reference counted pointers and compile-time
stuff though.

Any language that wants to _fully_ replace C/C++ has to embrace "pay only for
what you use". Mandatory _anything_ at runtime at the language design level is
untenable.

~~~
gjm11
> Any language that wants to fully replace C/C++ has to embrace "pay only for
> what you use".

"Pay only for what you use" _sounds_ like a really great principle. But ...

Every user of C++ pays the cost (in convenience and reduced bugs) of not
having automatic memory management, even if they don't need its benefits in
memory consumption and avoiding GC pauses.

Many users of C++ pay a _performance_ cost for the language's lack of
automatic memory management, because getting the best performance from an
automatic memory management system requires tight language integration and you
can't have that with C++. (So they fall back on refcounting or Boehm-Weiser-
like conservative GC, and pay the cost.)

Every user of C++ pays the cost (in ugly syntax and long compile times because
of the included-header model) of backward compatibility with C, even if they
don't really need that.

Many users of C++ pay a _performance_ cost for this, because the C++
compilation model means that template-heavy code tends to end up with a lot of
more or less duplicate object code, which means more cache misses and more
time spent paging code in from disc.

Every user of C++ pays the cost (in overflow bugs and the like) of using
integral types tied closely to the underlying processor architecture, even if
they don't need the performance advantages it brings.

Some C++ users pay a _performance_ cost for this, because if an application
actually needs bignums then it'll typically be implemented using some general-
purpose bignum system like GMP, which will typically perform very well for
really large numbers but may be totally unsuited for smaller ones -- and
sometimes most of the numbers you're computing with are in fact the small
ones.

C++ uses "pay only for what you use" as a slogan, but it applies that slogan
only in a very narrow domain. C++ users are paying, all the time, for lots of
things they don't use. Quite a lot of C++ users are paying in performance for
things they don't use. The slogan is misleading because it directs your
attention to the obvious, explicit costs of features like automatic memory
management and integer types that overflow gracefully, but there are plenty of
costs that aren't so obvious.

(Lest I be misunderstood: For many applications C++ is a great choice. For
some it's the only realistic choice. I am not, for instance, arguing that
actually everyone should be programming in Common Lisp or something. I just
think "you don't pay for what you don't use" is a really misleading slogan.)

~~~
Shorel
> Many users of C++ pay a performance cost for the language's lack of
> automatic memory management.

Now that's just empty rhetoric. What about 'users of Java pay a performance
cost for not having a stack, and creating every single object in the heap'?

I don't pay for unneeded garbage collection, and you can't use your rhetoric
around it.

~~~
snogglethorpe
Yup... I've seen a lot of java code aiming at high-performance that does
awkward/ugly things (e.g., class-static objects which are _actually_
constantly-reused temporary objects, manually-managed temporary object pools,
etc) to avoid heap-allocation, in cases where C++ code would simply use its
very natural stack-allocation.

