
Why C++ is back - devbug
http://devbug.tumblr.com/post/37058196342/why-c-is-back
======
marris
I think not.

The language is too big [it's always odd to see some people say things like
"the language is _still_ too big", as if some recent effort has succeeded in
making the language somewhat smaller, but not small enough... every recent
effort has actually made the language _bigger_ ]

There are too many ways to write bad code and too few ways to navigate bad
code. It's hard enough to pick up a big C# program and figure out what it does
... C++ is _not easier_.

I'm not sure why there's all this excitement over bit twiddling... every
language lets you twiddle bits. I can only assume the cool feature here is
mislabeled, and the authors are _really_ excited about _memory_ twiddling.
Fair enough. It's fun to write code that touches data structures at a byte
level. But it's _not fun_ to read/fix someone's buggy byte manipulation code.
If you're not writing a device driver, or your own compression library, then
you _should not_ do this.

Now, I am a big fan of people learning low-level system details, provided they
do it with some small C program, or by doing a project for their OS or
compilers class, or by _maybe_ working on some open source project.

But anyone who chooses C++ when he doesn't need it reminds me of the kid who,
rather than painting on paper, decides to paint on the carpet. You _could_ do
it. It's also probably a lot of fun. There's even the remote possibility that
you'll improve the carpet. But you probably won't. You'll probably just make a
mess. And it _won't_ be fun to clean it up.

~~~
jandrewrogers
In practice, C++ is considerably smaller than the theoretical extent of the
language. Every C++ code base I ever worked on restricted itself to a subset
of the possible feature space. With C++11, you can have a restricted subset of
C++ that is actually pretty decent as a programming language and relatively
easy to maintain.

With respect to bit-twiddling, the advantages of C/C++ are not intrinsic; many
other languages have broken implementations for this purpose. For example, a
glaring deficiency in Java is the lack of large unsigned integers which are
useful for many types of algorithms. You can always implement these algorithms
with signed integers but they may be much slower as a consequence.

For most people though, _memory_ control and optimization is the primary
reason to use C/C++. While I can see why it is difficult code for people
uncomfortable with it, I think you overestimate the complexity for people that
have done it for years. Like LISP, you have to become used to it. It is
similar to the reason why, despite some arguments, there are many huge C/C++
code bases that rarely leak memory despite very active development. Proper
idioms and use are a discipline like anything else.

C++ is never coming back for front-end applications. It is unnecessary and
inefficient for that purpose. However, on the server side (where I do
development), C/C++ is expanding very rapidly. Five years ago almost all of
the server engines I worked on were written in Java. These days, all new
development is in C++. The reasoning is pragmatic: C++ offers much better
performance and latency characteristics for server engines, primarily due to
its excellent memory behavior and efficiency. The latency and throughput
differences are often integer factor relative to other languages for server
workloads, so it is not a small difference and people are very sensitive to
operational costs and footprint these days.

I pretty much hated C++ for years but with C++11 it is not great but it is
adequate. Too much junk glued onto the language too many times. But until
something remotely as capable becomes widely used, C++ will be with us for a
long time, particularly as power efficiency becomes more important.

~~~
millstone
I don't agree that C++ is not coming back for front-end applications. There's
some currents against managed code (i.e. WinRT), but more importantly, it
never left.

I assume you are using IE, Firefox, or a WebKit browser to read this; that
means you are using a majority-C++ front-end app right now!

In web browsers, text editors, video editing, IDEs, games, etc, there's hardly
anything that can compete with C-derivative languages. Exceptions do exist
(Eclipse, Minecraft) but are universally slow.

~~~
politician
"IE, Firefox, or a WebKit" are shims which allow UIs written in high-level
languages to run on a variety of hardware. Their existence and popularity is
evidence that argues against your claim.

~~~
millstone
A shim is a thin and small piece of wood used to fill in small gaps. They make
a very poor analogy to web browsers, which are tremendously sophisticated
user-facing apps in their own right, and that dwarf the high level "UIs" they
support in complexity.

~~~
politician
Both Mozilla and Google consider their browsers to be shims for the underlying
OS. Firefox OS and Chrome OS betray that assessment. Accordingly, IE has been
historically crippled by Microsoft _because_ they realize that browsers
obsolete operating systems in many important ways for end-users.

Consider that operating systems are tremendously sophisticated user-facing
applications in their own right, and that dwarf the high level "web browsers"
they support in complexity. ;)

------
joe_the_user
I'm sad the article doesn't have give really good and substantial reasons for
c++'s continued popularity (whether c++ "is back" or "never left" is a
judgment call).

I would say that the basic reason is we still need systems that both customize
their low-level (literal and metaphorical) bits and use large scale, powerful
abstractions. Indeed, it worth remember that very high-level abstract systems
(such as databases) often wind-up simultaneously crunching lots of data in
unique ways and thus needs *particular" sorts of low-level operations along
with a variety of high-level constructs.

C++ has succeeded as a tool allowing you to do nearly any kind of abstraction
up from the low-level operations implicit in c. And given that this is a broad
mandate, the language comes out "too big" seeming, "too wordy" seeming and so
forth. Not a nice language but efforts targeted to a similar area have wound-
up making similar compromises and thus having equivalent problems (see the D
Language - not that its failure but that it seems to have failed to be lots
better than c++). C++ can be "the best language" (for its purpose) without
being "a good language" (without being a pleasant or sane-seeming language).

As jandrewrogers said, (at least the best) c++ projects use less than the
entire language and use it according to their needs. Merely having good parts
is not enough to make a language good but until we have a good alternative to
c++ or until we have garbage collectors and virtual machines that are
guaranteed to work best for any significant system whatsoever (good luck with
that), c++ will have a place.

~~~
kruipen
All your comments about practical values of C++ are good. But I would like to
point to something else: C++ is a smart, deep language. I mean this in a sense
that genuinely brilliant people get real intellectual satisfaction from
inventing and discovering C++ idioms and techniques. To me C++ templates rival
aspects of Haskell in the sheer expressiveness of a beautifully simple
concept.

------
cageface
When I started coding professionally in 1996 C++ was the go-to language for
all kinds of applications, many of which didn't require the speed or low-level
control of C++ at all. Predictably, this resulted in a lot of over-budget and
buggy apps written by people that didn't understand what they were doing.

Since then a lot of higher level languages and frameworks have whittled down
C++'s domain to what it is actually good for, and that's a _good_ thing.

But I write high-performance realtime audio software and C++ is really the
only language that makes that possible while maintaining a sane level of
abstraction.

------
PommeDeTerre
Huh, C++ is "back"? It never left! It has still been powering some of the most
complex, important and widely-used software systems the whole time, even if it
doesn't get the hype of languages like Java or Ruby.

~~~
devbug
Absolutely. However, the extent of C++ usage (and more generally "system
languages") has indisputably shrunk over a wide range of domains. Startups are
a great example.

~~~
shmerl
Look at Jolla startup. They use C/C++ primarily.

~~~
nohurr
Oh look, you found ONE. Good fucking job. If you look hard enough, you could
find one ANYTHING. It appears you really missed the point devbug was trying to
make.

~~~
shmerl
My point was, that start-ups differ. As well as technologies they focus on.
Not all start-ups are about the Web and frontend tech. Many are about backend,
others are about core technologies like mobile operating systems and so on.
Numbers are not the point. But significance and impact are.

------
mcot2
Once I learned Python, Java and C++ took a backseat for me on anything that
doesn't need to be fairly low level. Even for stuff that is low level I have
learned enough of the python-c api to connect things up when I need to
interface with c/c++ code. That's just me though... I write a lot of quick
data processing code that would be a lot of string manipulation mess in those
languages.

For writing operating systems, browsers, and other serious apps c/c++ is
pretty much universal.

~~~
dvirsky
Same here. I wrote shitloads of C++ in the past 10 years, but looking back, a
lot of this stuff could have been written in Python or similar languages.

Not being a hipster here, but I've experimented with Go lately, and while it
is not ready to become a main stream language - it is certainly a very
powerful one and a good replacement for a lot of the stuff I've been doing
with C++ and could not have been done with Python & friends. I'm glad it's in
my toolbox now.

------
tezka
none of the posts I read here mentioned the true advantage of C++ over other
languages: It's the only language that offers enough flexibility to write 1)
generic, 2) correct and 3) efficient code. With C you get only 3. With Haskell
you get 1 and 2. With ML you get some of 1 (yes I contend that C++, in the
hands of a competent programmer, can be as good as ML or even better for
writing generic code) some of 2 and some of 3. C++ allows you to have _cheap_
abstractions (using them does not require paying significant penalty, unlike
Scheme or Smalltalk). Java and similar managed languages excel in neither of
these criteria in particular.

~~~
tezka
Felt like expanding a bit more: Note that this is a result of evolution in the
language: What's referred to as modern style of C++ that has emerged from the
works of people involved in the STL/boost tradition and for the large part
informed the new standard. It's a noticeably different style from what you
would see in a codebase written in mid-90s. It's arguably less object-oriented
than most Java systems, and adopted certain concepts from functional
programming, while exploring several innovations hitherto unseen in other
languages.

What also enables this is advances in modern architecture. 64bit processors
allow for large address spaces and large stack frame sizes, which obviate the
need to allocate every single bit on the heap. You can often see sizable C++
programs measuring around 100KLOC or larger which use new/delete in a handful
of places. Automatic storage is, well, automatically managed. For when free
store semantics is needed, smart-pointers abstract the complexity of several
common cases where automatic-management is not adequate.

Using value semantics, streams, lambdas, regular expressions, and a good
library for command line flags processing (e.g., boost) C++ can even be a
perfectly apt choice of language for scripting. The development effort need
not be much longer than python but with no optimization the result can be
easily 10 times as fast.

~~~
zxcdw
It's nice to learn C, then learn C++98, then learn C++11, stick with it for 5
years and _still find that the language has 8379483 quirks you've never heard
of_.

Bjarne vouches for abstractions. Everyone does. What does Bjarne + standards
commitee do? Make old stuff useless, yet make sure the user _has to_ deal with
it. Make new stuff so the language becomes more complex. Why do we want
abstractions again? Because we want to get rid of _useless_ stuff and make
things _simple_ instead of make them complex! What does C++11 do? It goes to
the wrong direction. Very, very nice.

When will we have something simple instead?

~~~
bcoates
C++ abstractions aren't about making things simpler or about hiding complexity
from the programmer. They're about reducing duplication and allowing solutions
to be expressed in the domain of the problem. C++11 intentionally made things
more complicated to add more ways to do that.

------
halayli
You came back.

C++ is hard to appreciate without a good amount of programming experience.

A general pattern I am seeing is that programmers learn C++ as their first
language, move to Java, Python, etc.. gain some experience and then they come
back to C++ and say you know what, C++ is not that bad after all. But they
don't come to this conclusion because C++ changed, but because they learnt to
appreciate its usefulness.

After all, use the right tool for the job.

~~~
platform
There is a silver bullet that would make C++ very competitive for most of the
web/db centric apps:

It is Reflection/introspection capability built into the language.

Without it -- it is impossible to do DB structures to C++ structure mappings,
or UI fields to C++ structures mapping.

There are of course work arounds (QT's macros, pre-compilers, etc).

Every time I approached this topic with some in C++ community, the answer
always was ' C++ philosophy is -- if you do not use a feature of a language
you will not pay a performance penality for it'.

Reflection, obvsiosly adds performance penalty. When I suggest that it should
be a compiler switch (like RTTI) -- the reply I get -- is that reflection
cannot be turned on/off on per compilation unit., and instead must be on per
project level. But C++ standard does not define 'project level' compilation
option -- therefore, not acceptable.

That's pretty much where this discussion gets stuck

~~~
CCs
Indeed reflection is limited.

There's a library called Reflex: <http://root.cern.ch/drupal/content/reflex>

SOCI uses generic template accessors to read/write full objects:
[http://soci.sourceforge.net/doc/exchange.html#object_relatio...](http://soci.sourceforge.net/doc/exchange.html#object_relational)

------
Jabbles
Bjarne says that C++11 is a "new language", and I asked him back in May
whether there were any tutorials for learning the new idioms and styles. He
said "not yet".

Does anyone know if this situation has changed? I can see his new book on
Amazon is due out in March.

~~~
ekm2
C++ Primer has been updated for the new C++11,at least according to its
author.

~~~
zxcdw
This, and the Fifth edition is magnificent!

------
DanBlake
There is much hype now with going 'back to basics'. You get more cred saying
you are building things in C or C++ then you do if you are building them in C#
or similar 'new' languages.

However, one big fact that is being left alone here is that there is no
inherent speed bonus in using C, C++ or ASM over C# for most cases.

C++ apps can be faster than C# by a good margin, but you need to be able to
program better in C++ then the C# compiler does in translating your good C#
code. Simply writing in C++ != faster code. You have to beat the machine.

~~~
PommeDeTerre
I don't think it's about "going back to basics". I think that companies and
other organizations are just fed up with what they get when they don't deal
with C++ and C++ developers.

If they choose Java, they often get a slow, bloated, extremely over-
"engineered" system. Although simplicity is often given as one of the reasons
for using Java over C++, the complexity of these Java-based systems often far
exceeds what we see from even large C++ systems.

If they choose Ruby, they are almost guaranteed scalability problems if the
software is to be used by a large number of people. The effort and cost needed
to scale a poorly-performing Ruby on Rails web application, for example, can
exceed that of using a language like C++ in the first place.

When it comes to other languages, it may be difficult to find talented
developers. This can pose big problems when it comes to maintaining software
systems written in a more obscure language.

C++ has time and time again shown itself to be a safe bet. There is a large,
experienced and global developer community. There are ample resources and
tools available. It is extremely well proven, even for absolutely massive
systems. Systems developed using it usually perform quite well without much
effort.

It offers a better set of trade-offs than other languages. While it may take
longer to develop a system using C++, there is often at least equal, if not
much greater, time saving in other respects. Avoiding scalability and
portability problems alone can offer massive savings.

~~~
jrabone
With regard to java, a lot of the complexity is in ancillary systems rather
than language or the libraries themselves. You may not like Maven, for
example, but what's the c++ equivalent? Autotools? I think not. Any cross
platform c++ project immediately falls over the build system problem before
you write a line of code, and most of the time we choose a non-native,
underperforming solution (eg. MinGW on Windows) - anything for a quiet life.
Honestly, Java would be a better answer.

~~~
jongraehl
cmake or bjam

------
Aardwolf
It was never actually gone ...

------
halostatue
I first learned C++ with Turbo C++ back in 1989, 23 years ago. I have used it
professionally since 1996, 17 years ago. I've spent most of my career using
C++, and the startup I'm at now uses both C++ and Ruby. The only type of
compiler upgrade that I missed in my career was cfront to native (thankfully,
but waiting for compliance from compilers is painful). Now that C++11 is out,
everyone is claiming that C++ is back—when in reality, it never went away for
a lot of people.

Which is too bad. There's almost nothing about the language that makes it a
_good_ language. Even the so-called beauty of C++11[1] isn't usable by most
practical C++ developers at this point because they are stuck with compilers
that still struggle with rational C++98 and C++03 compliance (I'm looking at
you, HP-UX aCC). Or maybe they've got something that's older and mostly
compliant with C++98/C++03 because you have a hardware partner who only
provides something that is compiled with VS2005 and won't sell you the source
because you're not a large enough partner for them to give a damn. And gods
help you if you have an error related to templates unless you're lucky enough
to be using clang or can use an error filter to make the thirty thousand lines
of errors readable, even if they aren't directly applicable to the missing
semi-colon at the end of your class declaration.

It will be 2015 before most C++ developers can even _think_ of using anything
from C++11 in a production environment, if their (almost certainly mandatory)
coding standard allows for it. C++ _requires_ coding standards because you
really can blow off your leg.[2]

Not only that, features that would be vitally useful in many applications like
real introspection continue to be missing for no good reason at all. Multiple
inheritance is an absolute blight on the language, and the fact that the
`explicit` keyword even exists is problematic (or that constructors are, by
default, _not_ virtual).

All of that said, there's a lot of C++ code out there and it's a _good enough_
language for a lot of functionality, even though it's neither a humane
language nor a particularly secure language. There's a lot of libraries out
there, and they work reasonably well. For a lot of solutions, the problem
isn't finding _if_ there's a library to help you do something, but picking _a_
library from a couple dozen implementations and making sure that some other
library you depend on doesn't implement the same thing _differently_ …and then
making sure that what you pick actually works with the compilers you've chosen
or had forced on you.

If you're truly lucky, you work in an environment that lets you do the bits
that you must do in C++ without too much issue, and then you can use Python,
Ruby, JavaScript, Lua, or something else to drive the higher-performance code
with languages that better express business algorithms.

I'd still rather use Ruby for my whole program (when I had time for OSS
projects, I even _explicitly_ went with pure Ruby solutions because of
compiler issues), but there are places where C++ isn't just the right tool,
it's damned near the _only_ viable tool. A full stack developer needs to know
it. I'd argue that most devs should learn C++ just so they know how _badly_ a
language can be designed and still be useful for developing modern
software.[3]

[1] I'm sorry; the C++11 lambda syntax is unbearably ugly.

[2] <http://www.stroustrup.com/bs_faq.html#really-say-that> He tries to
backpedal from this truth. Other languages that are more expressive and IMO
more powerful because of the greater expressiveness do not offer the same
capability to break things as badly.

[3] Yes, I know. Most of the issues I have with C++ are probably fixed in
C++11. It's impressive. It's still a crappy language with even worse compiler
support. Far too much of the language is focussed on making me adapt to the
compiler, when with modern type inference and a little convention-over-
configuration or even _hinting_ , you could probably cut the size of any given
C++ program in half (in terms of number of characters) while not losing a
thing in terms of optimization.

------
pjmlp
When will these kids learn that Language != Implementation.

Back in the old days we used to say "I have a compiler/interpreter for
language X", not state that "Language X is compiled/interpreted".

Slowly I am starting to think it should be compulsory to understand compiler
design, before writing any blog entry about programming languages.

------
dotborg
Most of C++ production code I know, looks very similar to Java. memory
managers, garbage collectors etc. are being used, most of language features
are not used, so the code is simple, like Java,

Powerful language full of features yet programmers are scared to use most of
them.

