Review of Embracing Modern C++ Safely by John Lakos, Vittorio Romeo, Rostislav Khlebnikov and Alisdair Meredith
Wednesday, 01 March 2023
Verdict: Conditionally Recommended (3/5)
This is a huge book, over 1300 pages, and contains a wealth of information about all the language (not library) facilities added in C++11 and C++14. It has one "section" per language feature, and the sections are largely independent of each other, so they can be read in almost any order, and used as a reference. This is mostly a useful structuring, except for the few cases where there are closely related changes in both C++11 and C++14, and these are split into separate sections, that aren't even necessarily consecutive. Though there are already extensive cross-references between the chapters, the book would benefit from more cross references in such cases.
The word "section" is quoted above because they are what might be called "chapters" in other books. As it stands, the book has 4 "chapters", with "chapter 0" being the introduction, and the remaining 3 being what might be called "parts" in other books, and covering "Safe Features", "Conditionally Safe Features" and "Unsafe Features" respectively.
This use of the term "safe" is my biggest gripe with this book; much like a book on chainsaws might be titled "how to use chainsaws safely", the title makes the book seem as if it is going to be a tutorial on how to use modern C++ features without cutting your leg off. However, that is NOT the way that the authors use the word. They are using it with regard to "business risk" of adopting a specific language feature into a codebase that is mostly C++03 without providing explicit training to all the developers. Consequently the list of "safe features" is relatively small, and most features end up in the "conditionally safe" chapter, meaning that developers might need some training to use those features, rather than them being clear to developers only experienced with C++03. The authors explicitly call out that this "safety" axis is the one area where they intentionally deviate from their "Facts, Not Opinions" intent, and is the worst aspect of the book. As a general rule, developers should not be using language constructs they don't understand, so if a company wants to upgade to C++11/C++14 from C++03 then that company should provide appropriate training.
Consequently, I recommend that readers disregard the author's "safety" classification of the language features, and instead read the "Use Cases", "Potential Pitfalls" and "Annoyances" sections for each language feature and make up their own mind. It is particularly frustrating, since features that by and large make code clearer and less error-prone (such as lambdas, enum classes and range-for) end up being marked "conditionally safe" because they require training.
In the section on "Generalized PODs", the book covers what it means for objects to be "trivial", and be "trivially destructible", which are language constructs with specific meanings and consequences. They then go on to define their own term "notionally trivially destructible" to mean "those objects where the destructor has no code that affects program logic" (e.g. a destructor that only logs), and thus is safe to omit if you are directly controlling object lifetime (which should be a rare scenario anyway). This is not a language construct, and has no meaning to the compiler, but the similarity to the standard terms is too close and could easily lead to confusion. The inclusion of this in the book actually has the potential to decrease safety of a codebase, by encouraging developers to do things that might accidentally introduce undefined behaviour.
This book only covers the language features, not the library
features. Since a big part of the improvements from using C++11 and
C++14 comes from using the new library features (std::unique_ptr
vs
std::auto_ptr
, for example), this is a real let down, but given that
the book is already over 1300 pages, I can see why the authors decided
to leave it for another time.
Finally, this is a large, heavy book which makes it uncomfortable to hold it for any length of time, leading to contorted positions when reading. It is also a paper back book with very thin paper, so you can see print on the reverse side of the paper showing through, and a pale-grey font for comments in the example listings which is almost unreadable in many lighting conditions. This is particularly problematic, since many of the information in the examples comes from the descriptions of what each line means in the comment on that line. The e-book editions might thus be an improvement, though I haven't checked myself.
These gripes aside, there is a lot of useful information in this book. Each section covers a single language feature, how it differs from closely-related features in C++03, the precise details of syntax and use, intended use cases and potential pitfalls. If you want to know "how does this language feature work and what might go wrong", then reading the relevant section will give you a really useful set of information. You might still want to get training for the more complex features, but the sections actually contain enough information to get started, with copious examples.
In conclusion: this book is conditionally recommended. There is plenty of useful information there, but the presentation (both physically, and organizationally) is problematic.
Buy this book
Posted by Anthony Williams
[/ reviews /] permanent link
Tags: review, book, cplusplus
Stumble It! | Submit to Reddit | Submit to DZone
If you liked this post, why not subscribe to the RSS feed or Follow me on Twitter? You can also subscribe to this blog by email using the form on the left.
Design and Content Copyright © 2005-2024 Just Software Solutions Ltd. All rights reserved. | Privacy Policy
1 Comment
Thank you so much, Anthony, for your thoughtful and insightful review! I've already shared it with the other authors and we are discussing possible improvements for the next edition of the book.
Your feedback is genuinely very valuable, and I think that your overall assessment of the book is fair.
A few points I'd like to add:
- It is true that we use the term "safety" mostly as "business risk", but I'd also like to make it clear that there is a strong correlation between "business risk" and "chance to cut your leg off". It's not only about training. The examples you mentioned yourself are a proof of that: lambda expressions can easily lead to dangling references if one is not careful with default captures, and range-based for loops can lead to undefined behavior when looping over xvalue ranges.
- Disregarding the "safety" categorization in order for the reader to make up their own mind is something we do encourage, I believe we explicitly mention this in "Chapter 0". It's a completely valid (and intended) way of reading the book.
- Some mentions of Standard Library features are sprinkled throughout the book where appropriate, for example we do discuss `std::unique_ptr` in the Move Semantics section IIRC. But it is true that EMC++S almost completely focuses on language features.
- Your feedback about the "notionally trivially destructible" terminology is excellent. I am discussing with the other authors how to make it more clear that this terminology is not official and that relying on such properties of a type might lead to UB. If you believe that there are other parts of the book that might have a similar issue, please let me know -- the last thing we want is accidentally encourage potentially dangerous operations.
- Your feedback about the weight of the book is also important. We are considering splitting the book in separate volumes bundled together for the physical edition, just to make it more comfortable and easier to read.
- Your feedback about the print quality and comments in code is something we were aware of, and we are already working on the publisher to find a good solution. We have already tweaked the colour of the comments for the next edition on our side, but it is also a priority for us to ensure that the quality of the paper is better.
Again, thank you so much for the very valuable feedback. I am sure that even with its flaws, EMC++S can be an excellent companion for our intended target audience, and we are committed to making it even better in its future editions.
Cheers, Vittorio