C++ Frequently Questioned Answers

> What's the point of the language?

It's a drop-in replacement for C that is much more powerful and succinct.

C and C++ (and a couple of other languages like Delphi) provide naked, unprotected pointers, which implies almost full control over memory and the CPU that no higher-level language can give. With pointers you are closer to hardware, in other words.

On top of that, C++ has damn powerful meta-language facilities no other language of any level has, which are, however, beneficial only when in good hands. It's too easy to misuse C++ unfortunately.

I love advanced math.

But 99% of my life can be managed just fine with addition, subtraction, multiplication, and division.

It's that other 1%, though, where more advanced math kicks ass. If you've never seen it or watch it happen it's hard to describe how cool it is. With C++ you're controlling the CPU at a level just above machine language.

I love advanced math, but I rarely ever use it. Advanced math kicks ass.

The redeeming quality of C++ is that there's nothing better in its specific niches.

The question to ask is:

- do you just care about results: I need a program that produces these outputs when given these inputs

- or do you care about what actually happens: I want the computer to do this, then this, then this, in exactly this way please.

...?

It's usually a good idea only to care about the former -- the essence of functional programming, higher-order functions, etc., is to be able to focus on the former as much as possible -- and so long as you only care about the former C++ doesn't have much to recommend it except in special circumstances.

On the other hand, there are times when what happens, exactly is important (eg: device drivers, other low-level code, directly interacting with hardware, etc.). In that scenario what C++ offers is a language that standardizes a lot of the functionality that most sufficiently-large raw-C programs have implemented in an ad-hoc basis.

There are other ways of doing low-level code, but at the present time C++ is the best of bunch (or at least the safest choice if you have an eye to the long term), not so much b/c it's particularly awesome but b/c the others have either faded away for business or political reasons, or b/c the others made limiting choices (C++ makes very few decisions for you, which means it's equally suited -- or unsuited -- to every task in its particularly niche).

It is seldom a good idea, or even sane, to choose to machine something out of titanium (or beryllium). But sometimes there are reasons.

I think C++ does a decent job of being as logically expressive as practical while still supporting C-level memory micromanagement. Typically exposing C-level memory micromanagement issues is a bug, but occasionally it's a feature. So to me, the point of C++ is to express abstractions like polymorphism and exceptions in the same few pages of code as low level memory operations. How often do I want to do that? Not very often, but it can happen.

Also, while C++ is very hairy and I wouldn't want to have to implement it, C++ seems to be implementable enough and standard enough that it may be usefully supported on a platform well before other more expressive languages. Perhaps it's because a lot of the C++ hair is frontend target-independent stuff like parsing and templates, so that once you've ported the C backend you're almost done porting C++ too? Dunno for sure why, but it seems to happen: e.g., it was my impression on my Atari ST many many years ago, and is my casual impression that something similar happened for the Arduino more recently.

C++ is admittedly a weird mess in various ways, but given the choice of source almost-compatibility with C (which I don't particularly value, but which I can at least understand) and C-level linkers (which I have mixed feelings about) a mess seems inevitable. Thus, I still consider it an impressive design.

Occsionally I've seen IMO-excessively broad claims that higher level languages are the best. It sometimes makes me think I might be able to cook up an example where C++ would be hard to beat: a small backtracking search problem where trailing operations (in the sense of "trailing" that you'll see if you Google "trailing backtracking") are in the inner loop. Take this thought of mine with a generous amount of salt, because I've never boiled it down to a really clean challenge. OTOH, I have at least implemented such search in several languages, and I even did a few casual benchmarks --- but 10+ years ago, when performance tradeoffs were rather different.

That's a particular case of a general theme where C-level programming could win: performance dominated by a very simple memory allocation regularity (LIFO, in this case) that the GC doesn't know about. (This theme also involves the precondition that you should care more about a factor of 2 in performance than a factor of 2 in programmer time, which often doesn't hold.) In many instances of this theme, the accreted featuritis bloat of C++ would be overkill, so you'd prefer C. In this instance, though, placement new() of polymorphic objects into LIFO-allocated raw memory is more expressive than anything I can see how to do in C.

Now, we should not forget that many programmers can go all year without running into a single problem where a factor of 2 in performance is worth a factor of 2 in programmer time. And we should not forget that even the ones who need to care deeply about performance often find it's not determined by a few low-level hotspots where low-level tweaking helps. But in some subfields, it's not too unusual to rationally choose to micromanage stuff at the level of C/C++. (I nominate the subfields of embedded programming and compute-heavy search from personal experience, and Quake/Unreal-like engine programming by reputation; I also explicitly do not nominate implementing web browsers, ow ow ow.)

It's harder to think of reasons I'd choose to write sizable programs in C++ (other than the compelling but unsatisfying accidental-seeming reason of early availability on a platform). One reason, though, is that there are many subproblems for which the choice of language doesn't matter all that much. E.g., Fortran is adequately expressive for a lot of the stuff in a book like _Numerical Recipes_, and you can famously write Fortran in (almost) any language. Because of this, I sometimes encounter a program where some key subproblem really cries for a particular style of language, possibly C++, and then I can be language-agnostic about solving the other subproblems, not minding writing it in whatever language I chose for the key part.

Templates taking too long to compile and producing ridiculous error messages is actually one of, if not the, major complaints Yossi has about C++, though. One of the rarely spoken of differences between C and C++ is that the latter has a ludicrously slower compile leg of the compile/edit/debug cycle, and once you start digging into it, the slowness of compilation is built into the language (basically, matching template specializations is computationally hard), and is not an artifact of so-called "poor implementations."

C++ is so not perfect and is definitely not for large scale development. Read this: http://labs.mudynamics.com/2007/07/23/writing-c-within-ruby/

I think it's a bad practice in general, as it encourages nit-picking the small details and missing the main point of what someone says.

Even if programmers do something all the time, that doesn't mean it's right. The reason is simple: every opinion has arguments in favor of it. If someone offers five arguments in favor of an opinion, usually at least two are reasonable. If someone attempts to rebuke all five points, they're usually being unreasonable. It's also counterproductive, because bad counter-arguments call for counter-counter-arguments, which detracts from the actual points under discussoin. If you think an argument isn't persuasive and doesn't have much weight, then that is what you should say, instead of searching for some nitpicky way to counter the argument, usually ending up in discussions about semantics because you actually agree on the point.

As for this article: if this was intended to be humorous, then it contains far too much that seems to have been intended seriously, for my taste. After a few points he could have stopped beating the dead horse.

Wrapping criticism in humor is an annoying strategy similar to the 'poisoning the well' fallacy: as soon as someone tries to start a discussion, you can go "where's your sense of humor?" and your humorously wrapped argument remains unchallenged. That gets under my skin and may have impaired my humor detecting capabilities here.

No, GP's point is that there are garbage collectors for C++. I believe Stroustrup even mentions one in The C++ Programming Kanguage. Furthermore, you CAN tell the type of an object given a pointer to it, assuming it has at least one virtual function, using the typeid operator. As the GP said, the original quote is nonsense.

AFAIK it's reasonably well known as an unintentional troll - there was a stackoverflow question about the FQA (still looking for the link) that basically mooted almost every point.

I was reading it as a neutral party, however some very knowledgeable C++ appeared to convince all comers that the FQA is either based on ignorance or is disingenuous.

My disagreement has nothing to do with it -- the quoted remark was completely without basis in fact.

I used ellipses because none of the quoted argument was correct, and there was no point making a long quote, when a short one would suffice.

First, the premise was false: you can tell the type of a pointer to a dynamic object -- you use RTTI. You don't have to "guess" that the object is a Point, because you can use dynamic_cast<>() or typeid() to tell for sure.

Second, the conclusion was false: it is possible to write a garbage collector for C++. You cited a very popular one in your response.

So what do we have? You can tell the type of an object at runtime, and you can write a garbage collector for C++. When both the premise and the conclusion of an argument are incorrect, well...let's just say that it's hard to be less correct than that. It's Not Even Wrong.

As for your defense, let's be clear: you're not suggesting that it's impossible to "automatically collect the garbage of C++ programs" -- you're arguing that it's impossible to do it efficiently. I dispute that argument, too, but it has absolutely nothing to do with the comment that I quoted. It's a straw-man.

The bottom line is that the quoted statement was absurd, and you're only setting up a straw-man (about the efficiency of C++ GCs, and about the ability to drop them into large codebases.) We could perhaps have an interesting discussion about those topics, but our discussion wouldn't make the original article any less of a flame-bait.