The C++ Way. Part 0.

I’ve decided to write a series of posts on what I call “The C++ Way” analogous to “The Ruby Way,” a book and philosophy of the Ruby Language. After programming in C++ for years, I still struggle to think in C++. I constantly ask myself “what would Bjarne (Stroustroup) do (WWBD)?” when attacking a programming problem. This struggle to become one with the language — to understand the Zen of C++ — is a rite of passage that all C++ programmers must go through. C++ is a colossus of a language, built upon an ancient foundation (The C Programming Language), atop which feature is piled upon feature, resulting in an architectural nightmare akin to the Dark Tower of Barad-Dur in the Lord of the Rings. Its roots in the C Language result in a language that is “close to the medal,” in which pointers are actual machine memory addresses, in which you can shift and test individual bits in a machine word, in which you have to micro-manage your computer’s memory, so that you don’t end up with a memory leak or worse yet delete a pointer twice and bring on Armageddon. Its syntax is terse, to say the least, stemming from the days of clattering teletypes when it was worth naming the Unix command to unmount a disk “umount,” — the missing letter adding up over time to a savings of ink, paper, and sanity from the resultant slight reduction in teletype clattering. On top of this risky, high-level assembler base language is added support for classes and objects, albeit with so-called private members left hanging out fully exposed in public header files, much like the neighbor’s laundry hung out to dry (not the metaphor you were expecting?). The object oriented programming support is very good, including polymorphism, friend functions, pure virtual classes, public, protected and private inheritance, operator overloading, etc., etc. As every function and class needs to be declared before it is used, C++ code is divided between header files containing these declarations, and source files containing definitions. Header files can only be included once per program, forcing the programmer to use #ifdef and #define statements from the C preprocessor (thus using macros which are deprecated by the authorities for any other situation, but mandatory in this setting) to basically hack around a language limitation. Then there is support for another programming paradigm, generic programming, which seems to be the complete opposite to the OOP approach. Generic programming is implemented with templates, and allows the same code to be used with different types, as long as the types support the functions used in the template code. But templates can be used to create classes as well as functions, and these template classes can be polymorphic as well…. It’s certainly enough to create headaches, as well as providing source material for countless C++ programming books. Add in exceptions, namespaces, the Standard Template Library, and the rest of the kitchen sink, and you end up either appreciating the incredible subtlety of the language, or get tired of it all and program in Python.