Worst practices in C++, common mistakes [closed]

Question

After reading this famous rant by Linus Torvalds, I wondered what actually are all the pitfalls for programmers in C++. I'm explicitly not referring to typos or bad program flow as treated in this question and its answers, but to more high-level errors which are not detected by the compiler and do not result in obvious bugs at first run, complete design errors, things which are improbable in C but are likely to be done in C++ by newcomers who don't understand the full implications of their code.

I also welcome answers pointing out a huge performance decrease where it would not usually be expected. An example of what one of my professors once told me about an LR(1) parser generator I wrote:

You have used somewhat too many instances of unneeded inheritance and virtuality. Inheritance makes a design much more complicated (and inefficient because of the RTTI (run-time type inference) subsystem), and it should therefore only be used where it makes sense, e.g. for the actions in the parse table. Because you make intensive use of templates, you practically don't need inheritance."

Answer 1

First of all, his rant is really nothing BUT a rant. There's very little actual content here. The only reason it's really famous or even mildly respected is that it was made by the Linux God. His main argument is that C++ is crap and he likes to piss C++ people off. There's of course no reason at all to respond to that and anyone who considers it a reasonable argument is beyond conversation anyway.

As to what might be gleamed as his most objective points:

• STL and Boost are utter crap <- Whatever.
• STL and Boost cause infinite amounts of pain <- He's purposefully over-exaggerating, but then what is his real statement here? I don't know. There's some more than-trivially difficult to figure out issues when you cause compiler vomit in Spirit or something, but it's no more or less difficult to figure out than debugging UB caused by misuse of C constructs like void*.
• Abstract models encouraged by C++ are inefficient. <- Like what? He never expands, never provides any examples of what he means, he just says it. Since I can't tell what he's referring to there's little point trying to "rebut" the statement. It is a common mantra but that doesn't make it any more understandable or intelligible.
• Correct use of C++ means you limit yourself to the C aspects. <- Actually the WORSE C++ code out there does this so I still don't know what he's talking about.

There's no intelligible argument being made about anything. To expect a serious rebuttal of such nonsense is just plain silly. I'm getting told to "expand" on a rebuttal of something that I'd be expected to expand upon if it where I who said it. If you really, honestly look at what Torvalds said you'd see that he didn't actually say anything.

Just because God says it doesn't mean it makes any sense or should be taken any more seriously than if some random bozo said it. Truth be told, God is just another random bozo.

---

Responding to the actual question:

Probably the worst, and most common, bad C++ practice is to treat it like C. Continued use of C API functions like printf, gets (also considered bad in C), strtok, etc... not only fail to leverage the power provided by the tighter type system, they inevitably lead to further complications when trying to interact with "real" C++ code. So basically, do exactly the opposite of what Torvalds is advising.

Learn to leverage the STL and Boost to gain further compile-time detection of bugs and to make your life easier in other, general ways (the boost tokenizer for example is both type-safe AND a better interface). It is true that you'll have to learn how to read template errors, which is daunting at first, but (in my experience anyway) it's frankly much easier than trying to debug something that generates undefined behavior during runtime, which the C API makes quite easy to do.

Not to say that C is not as good. I of course like C++ better. C programmers like C better. There are trade-offs and subjective likes at play. There's also a lot of misinformation and FUD floating around. I would say that there is more misinformation floating around about C++ but I'm biased in this regard. For example, the "bloat" and "performance" problems C++ supposedly has aren't actually major issues most of the time and are certainly blown out of the proportions of reality.

As to the issues your professor is referring to, these are not unique to C++. In OOP (and in generic programming) you want to prefer composition over inheritance. Inheritance is the strongest possible coupling relationship that exists in all OO languages. C++ adds one more that is stronger, friendship. Polymorphic inheritance should be used to represent abstractions and "is-a" relationships, it should never be used for reuse. This is the second largest mistake you can make in C++, and it's a pretty big one, but it's far from unique to the language. You can create overly complex inheritance relationships in C# or Java too, and they'll have exactly the same problems.

Answer 2

I've always thought the dangers of C++ were highly exaggerated by inexperienced, C with Classes programmers.

Yes, C++ is harder to pick up than something like Java, but if you program using modern techniques it's pretty easy to write robust programs. I honestly don't have that much more difficult of a time programming in C++ than I do in languages like Java, and I often find myself missing certain C++ abstractions like templates and RAII when I design in other languages.

That said, even after years of programming in C++, every now and then I'll make a really stupid mistake which wouldn't be possible in a higher-level language. One common pitfall in C++ is ignoring object lifetime: in Java and C# you generally don't have to care about object lifetime*, because all objects exist on the heap and they're managed for you by a magical garbage collector.

Now, in modern C++, usually you don't need to care much about object life-time either. You have destructors and smart pointers which manage the lifetime of objects for you. 99% of the time, this works wonderfully. But every now and then, you'll get screwed by a dangling pointer (or reference.) For example, just recently I had an object (let's call it Foo) which contained an internal reference variable to another object (let's call it Bar). At one point, I stupidly arranged things so that Bar went out of scope before Foo, yet Foo's destructor ended up calling a member function of Bar. Needless to say, things didn't turn out well.

Now, I can't really blame C++ for this. It was my own bad design, but the point is this sort of thing wouldn't happen in a higher-level, managed language. Even with smart pointers and the like, you sometimes still need to have an awareness of object life-time.

*If the resource being managed is memory, that is.

Answer 3

The difference in the code is usually more related to the programmer than the language. In particular, a good C++ programmer and a C programmer will both come to similarly good (even if different) solutions. Now, C is a simpler language (as a language) and that means that there are less abstractions and more visibility into what the code actually does.

A part of his rant (he is known for his rants against C++) is based on the fact that more people will take on C++, and write code without actually understanding what some of the abstractions hide and make wrong assumptions.

Answer 4

Overuse of try/catch blocks.

File file("some.txt");
try
{
  /**/

  file.close();
}
catch(std::exception const& e)
{
  file.close();
}

This usually stems from languages like Java and people will argue that C++ lacks a finalize clause.

But this code exhibits two issues:

• One need to build file before the try/catch, because you cannot actually close a file that doesn't exist in catch. This leads to a "scope leak" in that file is visible after having been closed. You can add a block but... :/
• If someone comes around and add a return in the midst of the try scope, then the file is not closed (which is why people bitch about the lack of finalize clause)

However, in C++, we have much more efficient ways of dealing with this issue that:

• Java's finalize
• C#'s using
• Go's defer

We have RAII, whose really interesting property is best summed up as SBRM (Scoped Bound Resources Management).

By crafting the class so that its destructor cleans up the resources it owns, we don't put the onus of managing the resource on each and every of its user!

This is the feature I miss in any other language, and probably the one that is most forgotten.

The truth is that there's rarely a need to even write a try/catch block in C++, apart at the top level to avoid termination without logging.

Answer 5

One common error that fits your criteria is not understanding how copy constructors work when dealing with allocated memory in your class. I've lost count of the amount of time I've spent fixing crashes or memory leaks because a 'noob' put their objects into a map or vector and didn't write copy constructors and destructors properly.

Unfortunately C++ is full of 'hidden' gotchas like this. But complaining about it is like complaining you went to France and couldn't understand what people were saying. If you are going to go there, learn the language.

Answer 6

C++ allows a great variety of features and programming styles, but that doesn't mean these are actually good ways for C++ to be used. And in fact, it's incredibly easy to use C++ incorrectly.

It has to be learnt and understood properly, just learning by doing (or using it like one would use some other language) will lead to inefficent and error-prone code.

Answer 7

Well... For starters you can read the C++ FAQ Lite

Then, several people have built careers writing books about the intricacies of C++:

Herb Sutter and Scott Meyers namely.

As for Torvalds' rant lacking substance... come on people, seriously: No other language out there has had so much ink spilled on dealing with the nuances of the language. Your Python & Ruby & Java books all focus on writing applications... your C++ books focus on silly language features/tips/traps.

Answer 8

Too heavy templating may not result in bugs at first. As time goes on, though, people will need to modify that code, and they will have a hard time understanding a huge template. That's when bugs enter - misunderstanding causes "It compiles and runs" comments, which often lead to almost-but-not-quite-correct code.

Generally if I see myself doing a three-level deep generic template, I stop and think how it could be reduced to one. Often the problem is solved by extracting functions or classes.

Answer 9

Warning: this isn't nearly as much of an answer as a critique of the talk that "user unkown" linked to in his answer.

His first main point is the (supposedly) "ever changing standard". In reality, the examples he gives all relate to changes in C++ before there was a standard. Since 1998 (when the first C++ standard was finalized) changes to the language have been quite minimal -- in fact, many would argue that the real problem is that more changes should have been made. I'm reasonably certain that all code that conformed with the original C++ standard still conforms with the current standard. Though it's somewhat less certain, unless something changes quickly (and quite unexpectedly) the same will be pretty much true with the upcoming C++ standard as well (theoretically, all code that used export will break, but virtually none exists; from a practical viewpoint it's not an issue). I can think of few other languages, OSes (or much of anything else computer related) that can make any such claim.

He then goes into "ever changing styles". Again, most of his points are pretty close to nonsense. He tries to characterize for (int i=0; i<n;i++) as "old and busted" and for (int i(0); i!=n;++i) "new hotness". The reality is that while there are types for which such changes could make sense, for int, it makes no difference -- and even when you could gain something, it's rarely necessary for writing good or correct code. Even at very best, he's making a mountain out of a molehill.

His next claim is that C++ is "optimizing in the wrong direction" -- specifically, that while he admits that using good libraries is easy, he claims that C++ "makes writing good libraries almost impossible." Here, I believe is one of his most fundamental mistakes. In reality, writing good libraries for almost any language is extremely difficult. At a bare minimum, writing a good library requires understanding some problem domain so well that your code works for a multitude of possible applications in (or related to) that domain. Most of what C++ really does is "raise the bar" -- after seeing how much better a library can be, people are rarely willing to go back to writing the sort of dreck they would have otherwise. He also ignores the fact that a few really good coders write quite a few libraries, that can then be used (easily, as he admits) by "the rest of us". This really is a case where "that's not a bug, it's a feature."

I won't try to hit every point in order (that would take pages), but skip directly to his closing point. He quotes Bjarne as saying: "whole program optimization can be used to eliminate unused virtual function tables and RTTI data. Such analysis is particularly suitable for relatively small programs that do not use dynamic linking."

He critiques this by making an unsupported claim that "This is a really hard problem", even going so far as comparing it to the halting problem. In reality, it's nothing of the sort -- in fact, the linker included with Zortech C++ (pretty much the first C++ compiler for MS-DOS, back in the 1980's) did this. It's true that it's difficult to be certain that every bit of possibly-extraneous data has been eliminated, but still entirely reasonable to do a pretty fair job.

Regardless of that, however, the much more important point is that this is utterly irrelevant for most programmers in any case. As those of us who've disassembled quite a bit of code know, unless you write assembly language with no libraries at all, your executables almost certainly contain a fair amount of "stuff" (both code and data, in typical cases) that you probably don't even know about, not to mention ever actually using. For most people, most of the time, it just doesn't matter -- unless you're developing for the tiniest embedded systems, that extra storage consumption is simply irrelevant.

In the end, it's true that this rant does have a little more substance than Linus's idiocy -- but that's giving it exactly the damning with faint praise that it deserves.

Answer 10

As a C programmer who had to code in C++ due to unavoidable circumstances, here is my experience. There are very few thing I use that is C++ and mostly stick to C. The main reason is because I don't understand C++ all that well. I did/do not have a mentor to show me the intricacies of C++ and how to write good code in it. And without guidance from a very very good C++ code, it is extremely difficult to write good code in C++. IMHO this is the biggest drawback of C++ because good C++ coders willing to handhold beginners are hard to come by.

Some of the performance hits I have seen usually are due to the magical memory allocation of STL (yes, you can change the allocator, but who does that when he starts out with C++?). You usually hear arguments by C++ experts that vectors and arrays offer similar performance, because vectors use arrays internally and the abstraction is super efficient. I have found this to be true in practice for vector access and modifying existing values. But not true for adding a new entry, construction and destruction of vectors. gprof showed that cumulatively 25% of time for an application was spent in vector constructors, destructors, memmove (for relocation of entire vector for adding new element) and other overloaded vector operators (like ++).

In the same application, vector of somethingSmall was used to represent a somethingBig. There was no need for random access of somethingSmall in somethingBig. Still a vector was used instead of a list. The reason why vector was used? Because the original coder was familiar with array like syntax of vectors and not very familiar with iterators needed for lists (yes he is from a C background). Goes on to prove that a lot of guidance from experts is required to get C++ right. C offers so little basic constructs with absolutely no abstraction, that you can get it right much easier than C++.

Answer 11

Although I like Linus Thorvalds, this rant is without substance - just a rant.

If you like to see a substanted rant, here is one: "Why C++ is bad for the environment, causes global warming and kills puppies" http://chaosradio.ccc.de/camp2007_m4v_1951.html Additional material: http://www.fefe.de/c++/

An entertaining talk, imho

Answer 12

STL and boost are portable, at the source code level. I guess what Linus is talking about is that C++ lacks an ABI (application binary interface). So you need to compile all libraries you link with, with the same compiler version and with the same switches, or else limit yourself to the C ABI at the dll boundraries. I also find that annyoing.. but unless you are making 3rd party libraries, you should be able to take control over your build environment. I find restricting myself to the C ABI is not worth the trouble. The convenience of being able to pass strings, vectors, and smart pointers from one dll to another is worth the trouble of having to rebuilding all libraries when upgrading compilers or changing compiler switches. The golden rules I follow are:

-Inherit to reuse interface, not implementation

-Prefer aggregation over inheritance

-Prefer where possible free functions to member methods

-Always use the RAII idiom to make your code strongly exception safe. Avoid try catch.

-Use smart pointers, avoid naked (unowned) pointers

-Prefer value semantics to reference semantics

-Don't reinvent the wheel, use stl and boost

-Use the Pimpl idiom to hide private and/or to provide a compiler firewall

Answer 13

Not putting a final ; at the end of a clase declaration, at least in some versions of VC.