Olivier Langlois's blog

This is an editorial that I sent out to my LinkedIn C++ group members:
https://www.linkedin.com/groups/2035024/2035024-6089655206256144384

I'm discussing the retirement of of one of my favorite C++ books author: Scott Meyers
I am remembering the context when Scott Meyers books were hot and just out of the printers in the 90s. What other books of the same era that did pass as well the test of time.

I'm telling what he was meaning for me as a C++ developer and I am inviting people to discuss the impact and the causes of Mr. Meyers retirement.

Go read about it. It is very good!

This book has been published in 1993 and iostreams has changed a lot since then so this book is a bit outdated. Things that were not there in 1993 include:

• extension less header files
• std namespace
• IO stream classes were not templates
• No locale and facet classes
• classes that are now deprecated strstream

Surprisingly even with all these changes, most of the code in the book would still compile today. This is one sign that C++ designers took a great care to not break existing code unless absolutely necessary. The book is divided into different chapters. Materials that have still value today are:

• The first 3 chapters that explain why a programmer should prefer using io streams over printf
• The next few chapters describing the translator classes (istream,ostream,etc)
• Even if the code is rather cryptic in my opinion, there is a chapter that shows how to write table based extractor and inserter functions (operator<< and operator>>). One application of such function, for instance would be to implement a regular expression processor with a DFA.

There are easier ways to implement regular expressions with the boost library. The value that I see in the third point is that I have always kept my own operators << and >> very simple and I have found this part of the book was eye opening to what was possible to do with these functions.

The chapter that I have found to have failed the test of time is the last and very lengthy chapter that presents close to 50 small test programs so you could test that your iostream implementation was compliant with the latest C++ draft specifications for iostreams. At the publishing time, it was perhaps needed as C++ implementations were trying to catch up with a moving standard but today, iostreams specifications have been stable for many years. I think that it is safe to take for granted that your iostreams behavior is compliant with the standard or it should be a total shame for the library developer if it is not the case.

To conclude, since the book is still accurate on most points, it can still be handy as a reference if it is hanging around. However, at the same time, since iostreams have changed in subtle ways since the publishing date, I would recommend looking for a more recent book for a new purchase. I have not read it but 'Standard C++ IOStreams and Locales' might be a better choice.

I have got interested in this book because I have read from many sources on Mr. Koenig involvement in several key elements of the C++ language such as argument dependant lookup (ADL), also called the Koenig lookup, and the intersect rule for function overloading. In fact, if you read the book 'The design and evolution of C++', Andrew Koenig name is omni present throughout the book. So I was curious to see what Mr. Koenig had to say on C++.

Reading this book has been like a roller coaster ride. First, the cover is intriguing with its recursive pattern where you can see a girl under a tree in a field with cows in the background reading the 'Ruminations on C++' book with the same cover repeating itself over and over. Then the book is divided into six parts and, in my opinion, not all parts are equally good. The first part is taking a more philosophical view on what the C++ language aims to achieve. This part is not too technical and it has somehow a lot of appeal to my eyes. While reading this part, I was thinking that this was very promising for what was to come.

Then at the second part, it is where things are getting spoiled. Part 2 is describing basic C++ techniques. It is not bad but by having read tons of C++ books, to appreciate one of them, I must find some originality that I haven't found in part 2. This part of the book is average.

Finally, I have changed another time my opinion on the book when I have reached part3. Part3 covers templates and more specifically it recreates the whole though process that the STL designers went through to create STL. I see a lot of value to this kind of activities as I believe that understanding why certain things are done in a certain way can help you to better use those things.

In conclusion, I can recommend this book because I feel that mister Koenig goes beyond just the language syntax and try to teach a though process that someone has to go through to solve programming problems. This is a pedagogical approach not found in every programming book.

ACE is an amazing C++ application framework to create portable networked applications. I wish that I could praise as much the first volume describing this framework but it has some weaknesses in my opinion. It enumerates one by one the different low-level ACE classes that encapsulates, by using the wrapper facade pattern, the differences in services provided by the supported platforms. These services include sockets, threading, process management and synchronization primitives. One strong point of the book is that it demonstrates how using C++ features (like strong typing and RAII idiom) with ACE classes can make programs safer and less prone to bugs. The book also briefly discusses how to design networked services based on the service requirement. My complain about the book is that it covers many topics but since it does not focus on any of them, unless you are totally new with C++ or TCP/IP applications, it is likely that you will not learn much. You will find the book interesting if:

• You have not yet seen the benefits of abstracting the implementation from the users with OO encapsulation
• You have little experience in programming TCP/IP applications

My expectation for this book was that I would learn details about the inner working of the ACE classes. The type knowledge that should have complemented the official documentation provided with the framework. I have found out that it is not really the case. Except for less experienced developers, I think that someone should be able to become able to use all the covered classes in the book with only the documentation coming with the framework. There are few places in the book where I would have like to get this extra information such as in the section on ACE_InputCDR and ACE_OutputCDR or by making sure it is clear for the readers why calling ACE_Handle_Set::sync() is needed after having called select().

I have started to read the second volume and I believe that the second one will fit better my likings as it covers high level patterns built on top of the low-level classes presented in the first volume.

By having read the 3 books in the serie, I must say that this is my favorite because it has really answered a lot of small questions I had for a long time about several aspects of C++.

The only thing that I have disliked is that Mr. Sutter has contradicted himself with one of the advice that he was giving in the first book. The advice was to not write an assignment operator in terms of its copy constructor with the in place new operator and the explicit destructor and I did agree with the reasoning. Now in this book, it is written that is ok to use that idiom if and if and if and he goes for about a paragraph to describe the condition where it is ok to use the pattern. I can imagine that the author had to admit that there might be exceptional situation where it is ok to use that technique in a heated debate but my opinion is that out of context, he should not have mention that it might be ok to use that technique without devoting an entire item on that topic. It did just confuse me and I had to reread the item in the first book to convince me that there was effectively a contradiction between the 2 books and that it was not just my memory playing games with me.