Everything is seen as a bitstream

• pointers are just integers to memory locations
  – [25] integer and pointers might be indistinguishable in signature resolution
  
• code (CPU instructions) and addresses are treated the same way as a stream of data
  – concept of function pointers leads to lambda (functors)
  – classes came from structs containing data and function pointers (combined with namespaces)!
  
• unchecked type declarations: the compiler trusts your interpretations of data
  – leads to run-time features such as overriding (virtual methods)
  
• handles (pointers and references) has unrestricted power
  – [29] can const_cast it away if the handle is exposed (bad idea)

Performance-first design choice

• do not pay performance penalty for features not used
  – static compilation and binding by default
  – unchecked type declarations (see above)
  
• static compilation: the compiler tries to know everything at compile time
  
• static binding by default (cheapest)
  – pay extra to use virtual methods (overriding)
  – [38] default parameter values are statically bound and not stored in vtable (i.e. overridden child method’s default values are ignored and parent’s default values are used ONLY WHEN called through up-casts)
  
• inline is at the mercy of the optimizer (which can choose to emit an object if decided inlining is counter-productive). Mechanism that forces a function pointer to exist (pointing the function, virtual functions creates the pointer in vtable)

Toolchain

1. preprocessor (parser & macros)
2. compiler (create object files per translation unit, which is .c file in C)
   – access control (encapsulation) extends the old trick of emulating private in C++ through macros by marking functions as static (local within translation unit) in C.
3. linker (combine object files and adjust the addresses)

Templates behaves like a combination of macros (copy-and-paste with parameters) except it’s spread across the toolchain like inline optimizations:

• Code bloat (one copy per type combination)
• Can only live in the header files (it’s a template, not realized code, so no object is emitted like a .cpp file)

Parsing (language design)

• most vexing parse [Effective STL Item 6]: if something can be interpreted as a function declaration, it will be interpreted as a function declaration

Plain Old Data Types (C++ classes tried to emulate in their operator overloading behavior)

• [15] allow (a=b)=c chaining by returning *this for operator=
• [21] disallow rvalue assignment (a+b)=c by returning const object

If you’ve programmed in (or studied) C++ long enough, like you have read Scott Meyers’s Effective C++, which is a book organized in, jokingly, commandments like ‘thou shall make destructors virtual’. There’s a lot of stuff to remember.

I’ve found an approach to make the ideas stick: by understanding the rationale behind these commandments through the lens of ‘What would you do if you were to make C++ (features) out of C?‘

C++ is not a language designed from scratch. A lot of quirks and oddities in C++ came straight from the philosophy and the language features naturally available in C. With the right jargons (concepts), you will find a lot of the seemingly counter-intuitive behavior ‘it ought to be like this because of (insert design choice here)‘.

This is what we are going to explore in the “Rational Behind C++ Commandments” (RBCC) blog post series which came from my notes when I was going through Scott Meyer’s book. Once you get the ideas, you should be able to come up with the rules in Effective C on your own (so you don’t have to blindly remember them).