
Has C++ jumped the shark? - fogus
http://www.johndcook.com/blog/2009/08/18/has-cpp-jumped-the-shark/
======
faragon
I've written in C++ professionally almost 12 years (17 years counting
College), and in my opinion it is a shame how the language has not evolved
properly.

Unsolved things:

\- Unified C++ ABI call for making shared libraries without worrying about
compiler manufacturer or version.

\- Massive bloat. Take a look to the Boost libraries and cry.

\- Poor debugging tools for templates (debugging templates it is crazy, and
the promise of easy template debugging is almost a decade old).

Ridiculous things (in my opinion):

\- Obsession for doing everything in "user-land" (e.g. source code templates)
instead of built-in abstractions at object code-generation time instead of
compile-time.

\- Willing to introduce functional programing in the language, when, in my
opinion, it makes more sense just to interface with true functional code (e.g.
via SBCL).

C++ hour will come, with a non-bloated, system-software capable, "better than
C", which could be labeled "simple C++", as in "simple English".

~~~
timr
_"Massive bloat. Take a look to the Boost libraries and cry."_

Aside from your tears, what is the evidence that boost is bloated? Too slow?
Too much source code? Too many files?

I've been using Boost for nearly a decade. It does a ton of useful stuff (from
template metaprogramming to fast matrix algebra), it's loosely coupled, and
it's insanely fast. Given it's scope, it's the least bloated library of which
I know.

C++ _has_ been evolving, but for the last decade, all of the evolutionary
changes have come in the world of templates and template metaprogramming. I
think this is hard on the people who have restricted themselves to the C-with-
classes mentality. They're missing every modern development in the language
since ~1998.

~~~
wheels
> _ton of useful stuff (from template metaprogramming to fast matrix algebra),
> it's loosely coupled, and it's insanely fast_

It's actually not all that fast in a lot of cases. Boost's matrix manipulation
support is particularly slow:

[http://eigen.tuxfamily.org/index.php?title=Benchmark-
August2...](http://eigen.tuxfamily.org/index.php?title=Benchmark-August2008)

Also a lot of the template aerobatics generate a ginormous number of symbols
which massively increase the binary size and cache pressure. In a former life
I ripped out a pile of heavily templated code using Boost and replaced it with
a well placed virtual function or three and dramatically reduced the cache
misses in the application.

I've always seen Boost (and to a large extent the STL) as a demo library to
show off what's possible with templates rather than something to be used in
everyday code and have worked on a number of projects which forbade both.

There's a large rift in the C++ world between what I generally label Qt and
Boost camps. The Boost people see the Qt folks as Java-esque dimwits that
can't be bothered to learn the full extent of C++'s power and the Qt folks see
the Boost following as unpragmatic architecture astronauts.

~~~
timr
_"It's actually not all that fast in a lot of cases. Boost's matrix
manipulation support is particularly slow"_

You've picked a benchmark of the most highly optimized matrix algebra
libraries, and found that uBLAS is mid-pack, even though a) it isn't
particularly optimized for any platform, and b) its goal is to result in the
clearest possible syntax without sacrificing adequate performance. Talk about
picking nits.

 _"Also a lot of the template aerobatics generate a ginormous number of
symbols which massively increase the binary size and cache pressure."_

When it really matters (which it rarely ever does): man strip

 _"I've always seen Boost (and to a large extent the STL) as a demo library to
show off what's possible with templates rather than something to be used in
everyday code"_

I worked on shipping commercial products that used boost and the STL, and I
did nearly all of my speed-sensitive code with it in grad school. It's far
more than a demo library. Like I said before, you don't have to use all of it
to use some of it.

------
derefr
C++ is the only language I'm aware of where every extension made to the
language is careful to only affect _compilation_ time/complexity, while
preserving the speed and operational semantics of the code at runtime. This
makes it perfect for some domains, e.g. console game development, where the
speeds required are only attainable by dicking around with pointers in C, but
people want to use better abstractions than C is capable of. So no, continuing
to add those extensions is not wasted effort; we'll still be learning and
using them long into the future.

~~~
barrkel
This is thing that annoys me about C++'s illusion of control: unless you have
/ take full responsibility over the compiler and standard library, the
"control" that C++ gives you is actually an abnegation of choice which leaves
you to reinvent the world if you want specific features. What if you want
something like Smalltalk / Lisp images? Runtime code generation and
optimization of virtual method calls? Precise garbage collection? C++ leaves
you on your own if you want these things in your final executable, and you
have to work very hard - to the point of implementing a DSL, or writing /
modifying your own C++ compiler - if you do want them.

~~~
blub
"What if you want something like Smalltalk / Lisp images? Runtime code
generation and optimization of virtual method calls? Precise garbage
collection?"

What is the point of controlling all of those things? The GP was talking about
speed - how are GC, JIT and images related to this?

~~~
barrkel
Precise GC, JIT and images all give you more speed.

Precise GC is asymptotically more efficient than manual allocation; you need
to use other approaches, like arenas, to get back that lost time, but they are
not always applicable or easy to introduce.

Optimizing virtual method calls at runtime (e.g. monomorphic or polymorphic
inline caches) is rather awkward without JIT. Similarly, C++ templates cannot
be instantiated at runtime, meaning less efficient, more general and
indirected code needs to be used instead.

Images optimize startup hugely: they completely remove the need for any
initialization not directly related to acquiring external resources. For
example, this is one of the biggest reasons Chrome is so quick to start up -
it uses freeze-dried heaps in V8 (its Javascript engine).

~~~
blub
Ok, but:

1\. GC is fast at the cost of using more memory, which it turn slows the
entire app down. 2\. JIT can do all those optimizations, but how many of them
are done in practice? How fast is the software compared to a binary compiled
in C or C++? 3\. Can be useful, but the only software that I've seen having
trouble with startup times in the first place is written in .NET and Java :)

I guess that what I'm getting at is that C++ code is still faster than e.g
.NET code even if C# has GC and JIT. In the end that's all that matter, not
whether you can do optimization X.

~~~
barrkel
.NET code _is_ C++ code. The CLR is written in C++. In many ways this kind of
argument is pointless, because it's really about a way of creating a piece of
software, than particular to any one language. But some languages make life
really hard here - in C++, you need to build a runtime.

I'll assert that memory is not normally a constraint in most situations that
need to scale (i.e. not constrained clients), these days. (Though I will say I
have noticed that Firefox 4 is significantly slower than FF 3 when switching
tabs, and I believe it's because of memory reduction optimizations they've put
in because of everybody moaning about bloat. I'd prefer it use more memory and
less CPU.)

JIT optimizations like PICs? For over 20 years. The benefits are magnified in
languages that make many operations virtual, so you see it in things like
Smalltalk (very long time), Javascript (Chrome's V8) and Java JVMs (methods
virtual by default so it's a win).

Re slow startup - you're deluding yourself if you think there isn't much
software that doesn't have startup time issues. I need only restart any
machine I have to know how slow initialization is; with HDD transfer rates in
excess of 100MB/sec, there's no good reason for it to take more than 10
seconds or so when no hardware has changed. You're simply not aware of how
much faster things could be if startup were faster because you're used to how
slow everything is. You just know you can't e.g. fork utility X more than 200
times a second in a script, but don't realize it might be 10 or 100 times
faster with a different approach.

------
onan_barbarian
C++ has a fundamental problem: that of being a real language that added OO
features and static polymorphism in great haste; unwise decisions during the
early stages of C++ cannot be unmade after their negative consequences are
apparent.

There's some "good stuff" in C++1x, but of necessity, it's all additive, not
subtractive. So the language gets bigger and more complicated.

I've never met an adept C++ programmer who didn't aggressively cut the
language down to a subset. The sad thing is that I've met good C++ programmers
- and seen good C++ libraries and frameworks - whose subsets are quite
distinct; they are 'divided by a common language', like the old cliche goes.

------
arghnoname
The author says he is content with C++ the way it is, yet he bemoans the good
deal of time between major changes in the standard.

This is a little inconsistent. As a language that takes a long time to master,
changing fundamental features of the language every 3rd year, for instance,
would be a bit difficult to keep up with. Furthermore, the niche C++ lives in
isn't one that needs to change every year. For some users, language stability
and backwards compatibility are key, and with things like Boost, additions to
C++ can be tried out in the wild for many years before being standardized (as
many features slated for the newest standard were).

~~~
johndcook
I see how that could sound inconsistent. But I'm not bemoaning the time it
takes between changes to the standard as much as pointing out that these long
intervals show that the language is done. I'd rather see the standards
committee give up than hurry up.

~~~
dkarl
It's fine for a language to be "done" or "over." It's still important until it
has been replaced for practical purposes by another language. Until then, why
not keep making improvements? I wouldn't put C++ on my list of favorite
languages, but I expect my C++ skills to be an asset for a long time to come.

As always when talking about the continued relevance of C++, I will celebrate
when I'm proved wrong.

------
uuilly
Languages are tools. Da Vinci with a mop and a bucket of mud would be a better
painter than me. In fact I recently saw a video where Kelly Slater surfed a
door and a coffee table as impressively as most weekend warriors surf on $700
custom shaped boards.

Focus on your skill not the tools. Surfing is more about timing, fitness and
knowledge of waves than it is about the board. Likewise coding is more about
RAM, CPUs, HDs, GPUs, busses, networks and ultimately users than it is about
what tools you use to manipulate them.

~~~
CWuestefeld
_a video where Kelly Slater surfed a door and a coffee table as impressively
as most weekend warriors surf on $700 custom shaped boards._

I saw a table tennis player all excited about his new carbon fiber paddle.
Then one of the club champs picked up the box the new paddle had come in and,
using the box as a paddle, proceeded to defeat the player with the carbon
paddle.

~~~
calloc
I had a professor in University that beat some kid who thought he was all that
at Table Tennis with a shoe, a baseball bat, a piece of cardboard, an empty
plastic bottle, and then his bare hands.

It was absolutely hilarious how pissed this guy was getting with his fancy
paddle and his attempts at tricking my professor with trick shots.

------
ataranto
Since the browser most people are reading this in is written using C++, I'd
say the answer is no.

------
rbanffy
"Update: The ISO committee approved the final draft of the C++ 2011 standard
25 March 2011."

------
rch
"Collectively, the committee is responsible for billions of lines of code."

think about that a minute.

------
Luyt
I use C++ often, and what I'd like to see are good datastructures, built right
into the language syntax, like Python does that with dicts, lists, tuples,
sets etc... I know that STL has these, but using them still feels like some
grafted-on afterthought.

~~~
eco
TR1 added unordered maps/sets (hash tables) and tuples. Maybe it's because I
use STL every day but the interface works fine for me. It takes some getting
used to but it's pretty consistent. With the operator overloading it feels
just like any built-in language syntax (that's even more true with C++0x's
initializer lists).

------
echaozh
It's still C++0x though. The x is now officially B.

------
alecco
2009? news?

------
rakista
Don't make C++ into some fly by night whore language like Perl.

~~~
lawnchair_larry
Too late? :(

