

Surviving C++ - rcfox
http://c0de517e.blogspot.com/2011/02/surviving-c.html

======
dkarl
_In fact, no one uses straight C++ to make anything, in real world everyone
starts by sub-setting C++ into something "safer" and then adding back the
fundamental missing features (i.e. memory management, serialization,
reflection and so on) via libraries, macros or other trickery (i.e. code to
code transformers, code generators or parsers and so on), so really the C++ we
use is not a standard, but a studio specific version of the language._

I really don't understand this at all. He seems to be saying that using
"straight C++" would mean using the worst parts of the language in the worst
ways, but not taking advantage of the features that make C++ usable. If he
really thinks everyone uses macros, code generators, or code transformers to
do real-world C++, then he's wrong. I've been using C++ professionally for
almost ten years now, and I've never seen anything like that except: a few
legacy macro tricks that we easily replaced with better, non-macro techniques;
and Qt's preprocessor, which we never actually used in production code.

Style points for C++ have been rehashed endlessly. "C++ Coding Standards" is
pretty good IIRC: [http://www.amazon.com/Coding-Standards-Rules-Guidelines-
Prac...](http://www.amazon.com/Coding-Standards-Rules-Guidelines-
Practices/dp/0321113586)

For gaming and embedded software, you will need further rules for performance.
I'm not sure why this is a ding on C++. Doesn't any reasonably powerful
language have performance pitfalls? Don't use CLOS in your embedded systems,
folks.

 _C++ as a medium for our art looks more like statuary marble than modeling
clay: it requires a team of muscular stone cutters under the guidance of a
genius in order to produce some amazing sculptures. And once a given idea has
been translated into the stone, you hardy can change it without re-sculpting
most of it or having to work in the constraints that the shape it currently
has impose on you._

This is only true if your system is badly factored or if you are averse to
recompiling. "Ahhh, arrgh, no, I refuse to change the interface of this
fundamental class referenced by every other object in the system because the
next compile-link cycle will take ten minutes! I'll leave it crappy for the
rest of eternity just so I don't have to wait ten minutes for a compile, or
because my approach to changing this extremely fundamental class is to keep
making haphazard changes to its interface until my code finally works, so my
ten or twelve compile-link cycles will cumulatively take _almost two hours_."
Fine, we'll have an adult make the change instead.

Now I'm _really_ not suggesting that it doesn't suck when you have to wait ten
minutes to recompile your system when you change an interface that every other
source file in your system includes, but I hope recompilation time is not the
weightiest consideration in that case.

 _It's not a coincidence that the more a language is dynamic, the less need
there is for fancy debugging tools. Who needs a watch window indeed, if I can
just add on the fly a widget on screen that graphs the value of a given
variable?_

This is a legitimate complaint. Building instrumentation into a C++ system is
a pain in the ass, and it will never be as powerful as in a language with
introspection.

 _Well, the art of sculpting in C++, the art of design, becomes really the art
of subdividing our sculpture in pieces, the real design challenge is all about
how to cut or work into pieces. Too many of them and the sculpture will be a
fragile and ugly mess (translation: craptastically slow OOP shit). Too little
and we loose flexibility._

As far as I can tell, the point here is that if C++ was a better language, bad
design wouldn't be a problem. If it took C++ to drive him to consider OO
design principles, I'd hate to see the code he wrote in other OO languages.
Also, decomposition is not the only consideration. There are cross-cutting
concerns such as memory management, logging, and instrumentation.

The design principles at the end of the post are better and more
comprehensively covered by "Large-Scale C++ Software Design":
[http://www.amazon.com/Large-Scale-Software-Design-John-
Lakos...](http://www.amazon.com/Large-Scale-Software-Design-John-
Lakos/dp/0201633620) Some of the language points in that book reflect the
immaturity of C++ implementations when the book was written, but the design
guidelines are still relevant.

In general, it's very hard to say anything original about C++. Practitioners
and proponents of C++ are much more aware of its limitations than its
detractors realize. Also, this may come as a shock to the web generation, but
C++ is a topic that is very well covered by available books. Just as you might
browse through a few relevant blogs to see if someone else has already made
the same point you were about to make, with C++ you should do the same with
the highly-regarded books.

~~~
abcd_f
> If he really thinks everyone uses macros, code generators, or code
> transformers...

That's not what he was talking about. He basically said that if you take two
different teams, they will most likely use different subsets of C++ features.
One will be all about classes, hierarchies and (god forbid) boost and other
will be using C++ as beefed up C. That sort of thing.

------
timr
_"...Otherwise, the class has to have some data associated with it. Are we
sure we want to link Foo both to the interface of Bar and to its in memory
layout?

No, you are not. Don't do it, use composition instead. [More Effective C++, 33
Make non-leaf classes abstract]"_

Sigh. Dude either didn't read the book, or didn't think about what it's
saying; he's just quoting the chapter headings and drawing a silly conclusion.
Abstract classes can most definitely have data in them, and Meyers is _not_
saying that you should restrict yourself to object composition (he has a whole
section on how and when to use inheritance in the first book!)

The point Meyers was making is that if you're allowed to _instantiate_ a base
class that implements an assignment operator, you can easily get into a place
where you can do bad, mixed-type assignments. If you make your base classes
abstract, you can prevent this problem -- hence the chapter title.

This isn't the only bit of bad advice in this blog post -- just one that I
picked out at random. It's another example of a rant by someone who knows just
enough about C++ to be dangerous, but not enough to be insightful. Flagged.

~~~
gte910h
This is the issue with C++. This level of knowledge of any other language
you'd be fine to let the guy do some code. You have to have considerably
better developers.

With C++ you have this huge dearth of people who know enough about the
language to convince someone else of it, then you get them on your project and
they blow stuff up by doing it subtly wrong.

C++ has uses, but it's the sulfuric acid of programming languages: you have to
have good personnel control and fire those who screw around outside the
boundaries of the right style. A programming group with one guy programming
like C with classes and another guy programming like it's Ocaml without
garbage collection, and you're in for a mighty piece of hell.

~~~
timr
_"This level of knowledge of any other language you'd be fine to let the guy
do some code. You have to have considerably better developers."_

Don't tell that to every Ruby and Python startup that's hiring "rock star"
developers. You might hurt their feelings.

At the end of the day, you want the best programmers you can afford on _any_
project, so I don't think it's a particularly compelling argument to say that
Blub is a better language because it lets less-qualified people get work done
faster.

That said, this guy _gives the impression_ of being competent at C++, but most
of his advice is really quite bad. It's fairly easy to write and informed-
sounding rant about Python or Ruby, too. The difference is that more people in
this forum know those languages, so they're more willing to call bullshit on
the poseurs. The level of C++ (and C) competency in the web world is, frankly,
disturbingly low.

~~~
gte910h
>At the end of the day, you want the best programmers you can afford on any
project, so I don't think it's a particularly compelling argument to say that
Blub is a better language because it lets less-qualified people get work done
faster.

That's complete pap. Of COURSE you want less capable people to get things
done. That's the entire point of junior and midlevel developers. Less
expensive is sometimes (not always) more useful than being super great. You
act like only very good dev's with 8-13 year of industry experience are any
use at all with that attitude. Some things really shouldn't require geniuses
to do.

~~~
timr
_"You act like only very good dev's with 8-13 year of industry experience are
any use at all with that attitude. Some things really shouldn't require
geniuses to do."_

You're overstating the claim. You don't need to be a "genius" to be productive
in C++. Yes, there's a learning curve. It _may_ even be a little steeper than
in other languages, but it's entirely possible for a smart new grad to
contribute meaningfully to a large C++ project. It happens at Microsoft and
Google and thousands of other companies _every single year_.

This line of argument against C++ is entirely overblown.

------
tspiteri
I really don't see the point of the tone the article adopts. If it is aimed at
C++ users, badly mouthing C++ can only put them off what could be useful
advice. If it is aimed at C++ bashers, they don't need the C++ advice anyway.

~~~
udp
Bad mouthing of C++ has become a popular thing to do lately. I think it's
partly because C++ is a difficult and time consuming language to learn with
many caveats, and people find it easier to give up and bash it instead.

Just because C++ doesn't feel as "clean" as other languages doesn't mean it's
not incredibly powerful, widely supported, and a fun language to develop in.
To all the haters out there - give it a chance!

~~~
Jeema3000
But the main reason it's not as clean is because it has had to maintain
backwards compatibility with C, which is 40 years old now.

Ironically, had C++ been 'cleaner' and not as backwards compatible with C from
the outset, then we probably would not be having this conversation today
because no one would have ever adopted it. :)

~~~
dantle
Can you give an example of removing some backwards compatibility with C that
would make C++ cleaner?

~~~
WalterBright
Converting static array references to pointers when passing them as a function
parameter. The whole array/pointer conflation.

C's struct "tag name space".

Trigraphs and \ line splicing.

Replace #include with symbolic import.

------
georgieporgie
_Should we consider using PIMPL_

No. Just don't.

I'll say this about C++: the worst thing about it is that each new job
requires you to learn what is 'good' and what is 'taboo' at the new company.
One man's natural and elegant is another man's obtuse and illegible.

~~~
jmspring
Your thoughts are exactly what I have encountered in the last 10 years.

The author of the article really gives me the impression that he should just
really stick to ruby and have his lolz.

C++ is a language, it has slowly evolved over 15+ years, it isn't the
prettiest thing. Different people use different parts. Deal with it. If you
don't want to work with c++ find a job doing something else.

