Archive for the ‘ Effective C++ ’ Category

Effective C++: My understandings of the items from the book – 1

I’ve recently finished reading what is widely regarded as the goto book for learning the best practices for writing clear maintainable code in C++: Scott Meyer’s Effective C++.
I thought, as a way of better committing what I’ve learned to memory, that I’d summarise each topic that the book covers. I also thought, why not share my thoughts with the world, in case anyone else would benefit from the slightly different perspective I’ll have.

The first point in the book is that C++’s weird rules that often seem quite inconsistent are made simpler when you think about the language not as a single language, but as a few related languages:

  • The C part:
    This is the base part of the language, the parts that C++ shares with C. The idea of headers, blocks, statements, parts of the preprocessor including #defines and #ifdefs etc (but not templates). The built-in types are also in the C part – these are the types which in the Java world would be called primitives. This includes all the ints, pointers, bools (even though C didn’t have bools until C99), floats, doubles, etc, but excludes things from libraries and classes. Non-member functions are also C like.
    Things done in the C style tend to pass-by-value (well technically everything is always pass-by-value in C++, but with OO C++ we can hide that so it practically becomes pass-by-reference (I don’t mean c++ references)).
  • The Object Oriented C++ part:
    This is the standard C++ part, with classes, constructors, methods, exceptions, polymorphism, inheritance, encapsulation, virtual functions / dynamic binding, namespacing, etc.
    The size of the objects here tend to balloon quite a lot so passing-by-reference is usually preferred.
    To reconcile this with the claims that everything is pass-by-value in C++: to pass-by-reference, you pass an object with pass-by-value but the object is a reference, by which I mean a pointer or a reference (to const, usually).
  • Template C++:
    This is the crazy part of C++ where you tell the compiler to write the code for you. There’s plenty of gotchas and rules which apply to C++ in general but don’t apply to templating and vice-versa. This is also the part which gives rise to the other paradigms that C++ apparently supports, as templating is turing complete in itself, but such template programs run entirely at compile time.
  • The STL:
    This is the part of the standard library which came from the Standard Template Library. This includes all the useful new types that you get with the stl:: or std:: namespaces, like strings, vectors, maps, trees, algorithms, etc. This stuff is so magical that there’s a whole nother book in this series specifically about using the STL effectively, but simple usages are relatively straight forward, at least in my experience.
    Beware though, although using the STL feels a lot like OO C++ part of the language, it also tries very hard to mesh into the C part of the language, so you’ll often find that the C style rules apply to the STL rather than the OO C++ style rules.

 

Since reading this book I have found that C++ has sat much nicer in my mind, being able to organise the different behaviours and conventions into these 4 categories has helped to clarify and explain some of the quirks.

%d bloggers like this: