Idiosyncratic C++

Happy St. Patrick’s Day!

Years ago I was in Florida courting a prospective customer.  In one of our initial biz-dev meetings, we were trying to get our arms around the opportunity, and were a bit paralyzed.  Finally, Jack, the customer’s colorful VP of Sales, said “what we need is a dead cat!”.  My partner and I looked at each other blankly.  Jack explained, “A dead cat is a brainstorming technique we use.  Someone puts a lousy idea on the table to get started.  Everyone takes a look at it and says, ‘We don’t know what we want, but we know it’s NOT THAT!’ ”

Sometimes, a good way to understand something is to identify what it is not.  With that technique in mind, I’m going to start a series of posts on idiomatic C++.  In each post, I’ll start with an anti-pattern or two of what Andrei Alexandrescu calls “C+”.  Rather than being idiomatic C++, we might call this style “idiosyncratic C++” (“idiotic C++” is probably too strong).  Many arrive at idiomatic C++ by way of idiosyncratic C++, particularly if they’ve come from other languages like C or Java.  They’ve learned the hard way how to write safe, efficient, maintainable, platform-independent C++ in a conventional style – in short, idiomatically.  Those trench experiences are gold <insert tenuous tie-in with St. Patrick’s Day pot-of-gold image>, and worth exploring and sharing.

My working definition of idiosyncratic C++ is:

Idiosyncratic C++:  Code that a compiler will accept, but a reviewer should not.

In this series, I’ll cover topics such as:

  • Using The Heap
  • Structured Code
  • Eager Evaluation
  • Naming Conventions

I’m open to requests and feedback.  Send them in and stay tuned…