C++ Common Knowledge

Inspired by my friend Ranjit's web-site, I have also decided to give it a try and make jot down some notes on the books that I read, both technical and non-technical. Here it comes.

My first attempt is C++ Common Knowledge by Stephen C.Dewhurst. The blurb on the back page of this book says that this book is for you "if you've had some experience in C++ programming, but reading intermediate and advanced C++ is slow-going". I will have to agree with this assessment. The book intends to list of out some essential tips and practices for professional C++ programmers and clearly achieves it.  One word of caution -- As there are no exercises at the end of the chapters, we need to resist the temptation to just flip the pages and treat it as a light read, the contents have to be chewed and digested for maximum benefit.

The book has a total of 61 chapters and of these, I felt I have learned something new (or presented something I knew in a new way) from quite a few of these chapters. I skipped the STL related common senses as I thought I need to get some "basic sense" of STL before learning advanced "common sense".

For those who already are familiar with a lot of these, this book presents enormous opportunity for composing C++ interview questions, if not anything else :)

Of the chapters I did read, here are some notes:

1. Chapter 11. "You do not get what you see". I have never assumed the location of the virtual function table pointer or other data members in a class and I was amused to see that some people try to get into that detail. Nevertheless, the fact that compiler can possibly rearrange the data members, irrespective of the order in which they were declared, was new.
2. Chapter 14. The name of the function is the same as its address. What happens when you take the address of an overloaded function? Is this allowed? I learned from this chapter that this is indeed allowed and that the compiler uses the type of the pointer is used to select among the various candidates.
3. Chapters 15 and 16. Pointers to class members and Member functions. Well, to be honest, I had never used these and somehow I have a feeling that I will never need to use them, but the fact that these can be done and that de-referencing the class members actually gives an offset (from the start of an object) rather than an address was something new for me.
4. Chapter 18. The idea of using the Fibonacci series to illustrate the benefits of using function object instead of a function pointers was nice. It drove home the point pretty well. Just for reference, function objects are like smart pointers where the function call operator () is overloaded.
5. Chapter 20. Like Chapter 18, the examples of the using function object as comparator was a good idea. Introduction to std::binary_function and std::unary_function was welcome.
6. Chapter 22. Template Method terminology. Basically this is the idea that the base case establishes the contract with its users and that derived classes need to uphold the contract.
7. Chapter 23. I am also guilty of the folly listed in this chapter -- putting the using directive (for namespaces) at a global scope. I usually use it for "using namespace std" and I do not think I would ever name a variable from the std library, but I agree with the author wholeheartedly that this is not a good practice.
8. Chapter 29. The concept of virtual constructor by indirect invocation of class's copy constructor, to clone for example, is worth knowing.
9. Chapter 33.  Using destructor as pure virtual is a good choice for coercing a class to be abstract. This is interesting.
10. Chapter 39. Minimize usage of try blocks and use them at module boundaries between your code and third-party libraries and also your code and OS. Something to think about.
11. Chapter 40. RAII explained with the ResoureHandle example was great.  The idea is that you acquire your resource in your constructor and release it in your destructor and make sure you use local variables so that destructor is automatically called when the function ends.
12. Chapter 63. You can omit virtual keyword when you have overriding a parents virtual method. No big deal, but new nevertheless.