C++ pitfalls

C++ is a powerful language, but “with great power comes great responsibility” so it’s quite easy to mess things up and to make mistakes that can lead to unexpected results and miserable fails.

In this post I’m going to describe 8 not-so-obvious aspects of C++ that can lead to bugs or to code which doesn’t even

7 Comments

  1. Jacob

    Thanks for sharing

    Reply
  2. jonathan

    Thanks. I find it helpful to have things like these pointed out.

    Reply
  3. Ariel

    Thank you! Excellent points. I have struggling with similar things while debugging, I wish I had read this then.

    Reply
  4. DeadMG

    A couple of these are nasty or subtle, but some of them are just PEBKAC moments.

    #1- that’s just the basic usage of references. This isn’t tricky or subtle, it’s their exact intended use case. If you were expecting anything else, then the means by which you gained those expectations is less valuable than an American subprime mortgage.

    #2- This is unfortunate. We get asked regularly about this. But it’s not really a terrible pitfall in that the compiler gives you a clear error when you try to actually use the object, and anyone who has experience in C++ knows what’s going on here. It’s an unpleasant surprise for the newcomers, but not a serious problem.

    #3- I admit this can be somewhat nasty, but most compilers will warn if your initialization list order is different to the actual initialization order.

    #4- Inlining is an implementation detail. The inline keyword actually refers to inline function definitions in source code w.r.t. ODR, not inline in any generated code (if, indeed, any code is even generated).

    #5- You asked for a Base. You got a Base. What could the result of casting to Base be, if not a Base? If you wanted a reference to the source, you should have asked for a reference. You got, entirely and exactly and quite literally, what you asked for- a Base value.

    #6- This is actually an exceedingly complicated topic. Again, this is really a compiler implementation detail that has little significance to the end-user, except that if empty classes had zero size, a lot of code dealing with memory would be substantially more complex. The Standard saves you from handling them as an annoying special case in lots of places by mandating that a class must have at least size 1. Reducing any size is, of course, a compiler-dependent optimization that is an implementation detail.

    Frankly, if you’re going to name C++ pitfalls, please pick things which are actually serious issues. It’s not like there aren’t plenty of those.

    Reply
    1. r00t (Post author)

      It may sound weird to you, but what’s stupid/simple/easy/boring to you may not be the same to someone else and sorry to break your heart, but I didn’t write this post just for you.

      If you don’t want to call them pitfalls you can call them gotchas.

      Reply
      1. Nicolas Olivier

        Thanks for the notes. I keep a file of careless errors – sometimes you can sidetrack yourself looking for more complex design errors – and its always good to remember the ones that are easy to over look.

        Reply
    2. Nicolas Olivier

      A bit snitty don’t you think ? This blog is not just for gurus.

      Reply

Leave a Comment

Your email address will not be published. Required fields are marked *