C–

I'm surfing C++ entries on Wikipedia…and it's reinforcing my belief that the best use of C++ is to ignore most of the language. Simply put, I consider C++ to be too feature-rich for serious industrial programming. Off-hand beer-induced rules of thumb:

• The choice to use a C++ feature should be based on maintainability and debugability, not just the ability to code it. In particular, take a good look at how badly most debuggers handle very complex templates, then think twice before building some kind of monster templated data model. (I've done this, and man does it burn you later.) It better be worth some pay off, because you will pay for it with debugging.

• In that spirit, don't go too crazy with templates. Templates are cool and can do some things very well. By all means use vector and map. But at some point too many templates will cause your compiler to lose its mind and generate tons of slow code. Compiler technology continues to get better and better, but C++ templates can demand a lot.
• Avoid operator overloading unless the use of the overloading is so blatantly obvious that even a monkey could figure out what you mean. It's too easy to get clever with operator overloading and make code that's totally impossible to understand. + should mean plus, * should mean multiply or dereference, and if you're not sure which one, don't overload operator* at all!
• If you need a pointer to a member function, your design may be screwed up.
• Think twice about function overloading. It's not inherently a bad idea (unless the function is virtual, no pun intended) but you can always make the names more descriptive and the code more maintainable.
• I believe that private inheritence and pure virtual inheritence are both signs of a problematic OOP design, but that's a complex enough subject that I'll have to write a separate rant about it. I will just say here that private inheritence and virtual base classes are two features you shouldn't need to use a lot.
• I have a psychotic hatred for iostreams. That'll have to be a separate rant too, but for now: if you're going to invest time to learn a byzantine cross-platform I/O API, learn stdio, not iostreams. You can use it in pure C code too, and someday when you have to write code with moderately good performance you'll be glad you did.

Scott Meyers said it best in Effective C++: say what you mean and understand what you say. By far the biggest challenge of programming is programming itself, that is, dealing with piles of code, especially when it's not yours or you haven't looked at it in three years. To that end, if a C++ feature makes it hard to understand what you're saying, I say don't use it.

The Fine Print…

http://developer.apple.com/documentation/developertools/Conceptual/CppRuntimeEnv/Articles/LibCPPDeployment.html Little did I realize that Apple only started providing libstdc++ at the last second. My take on all this is: the GCC 3/4 transition is a little more painful for Mac developers than it would have otherwise been because of the Intel Macs. Normally the workaround would be to sit on GCC 3 for a while for compatibility, but only GCC 4 has x86 support on Mac.

With Syntax Like This…

…who needs enemies? I wrote this code for a GUI_ScrollBar, a derivative of GUI_Control that overrides a function, calls the base, then refreshes itself. Ignoring all of the sins of a design like this…

void GUI_ScrollBar::SetPageSize(float inPageSize)
{
GUI_Controll:SetPageSize(inPageSize);
Refresh();
}

What does this code do? It loops forver and overruns the stack. Here's a hint: two L's and one colon, not one L and two colons. Now here's the cute part…there is no entity GUI_Controll with two L's anywhere. Why does it compile? This is an exercise left to the reader, one that may make you want a drink.