(Following up from redi
anti-C++ rant and my
earlier response...) On re-examination, I find Avery is
wrong in practically
every detail, most probably because he started out and still
lives in the world before
there was a Standard C++.
Redi already noted that the Return Value Optimization
(RVO) doesn't depend on inlining, and that Avery's example
doesn't depend on the RVO anyway. I will add that RVO is
implemented in every extant compiler, so you should
think of it as a regular language feature.
Avery complains vaguely about C++ exceptions, but
C++ is the only language where exceptions actually work.
That's because C++ is the only language that has real
destructors. Other languages need a "finally"
construct, which obliterates most of the potential benefit
Everything Avery complains about in
std::string is a feature; i.e. it has 99 problems, but
Avery's ain't them. If you find yourself making a string
class, you're wasting somebody's time. If your function
would be just as happy with a const char*, then make it take
a const char*. I don't make my own string types; I use
either std::string or char*, and one or the
other always does the job.
Avery's complaints about function pointers are just
weird. In most places where you would have used a function
pointer in C, you want a virtual function in C++. That's
close to the only place where virtual functions are actually
useful (which makes it criminally idiotic that virtual
functions are the default in Java, but I digress). Most
people don't find it immediately obvious how virtual
functions fill in for function pointers without looking at
actual examples. Now that you know, though, you can look for
So, if in all of Avery's examples he's wrong, where is he
right? He's right that C++ code cannot be made as pretty as
code in a slow language, and that it's a mistake to
try. C++ code is always going to look kind of clunky. The
knack is to know which kinds of clunkiness are essential,
and which are your fault because you didn't think clearly
about what you are doing. If you find yourself overloading
operator or fooling around with exotic function pointers,
it's probably the latter. Coding good C++ is a lot like
chess; ask yourself, "does this line help solve an actual
problem?" If not, it's likely to be procrastination, or
over-engineering, or wankage. It's not to C++'s credit that
you have to ask yourself that, but no language deserves the
blame for your own dilatory impulses.
What sucks most is that there is no useful and pretty
language as powerful as C++, and none being worked on, so
those of us doing hard things will depend on C++
indefinitely. Other, slow languages will come and go and be
used for easy problems, as Bram's Law predicts.