Verdict: Not recommended

I tend to be a fairly soft reviewer, and it pains me slightly to give bad reviews, but this book did not agree with me. It’s been a long long long time in the coming, and I found myself disappointed with the result. So what is in it? The strong point of this book is that it is pretty much the reference on physical design. After over 100 pages (!) of introduction, Chapter 1 covers compilers, linkers, dependencies and level numbers. This is all quite good and interesting, and I wish that Chapter 2 had been perhaps 100 pages of so saying (once, and only once) that dependency cycles are bad and these are the packaging and levelization techniques that you can use to improve your design. But no, Chapters 2 and 3 that cover these topics go on and on and on, often repeating the same ‘cycles are bad’ mantra for over 600 pages. I got the message, John. When reading this part of the book I wondered how many people will really apply these principles to their build systems. Is Bloomberg bde the only place where all these ideas have been fully applied. I’ve never used bde, and I wonder if it was worth all that effort.

The previous edition of this book is famous for only being remembered for espousing external include guards. 30 years of Moore’s law means that what used to be a major bottleneck when building software is now so insignificant that it is difficult to measure. However, we still get 4 pages on the subject, but on a grey background and marked as (deprecated). Perhaps for the sake of nostalgia?

The book contains many forward references to Volumes 2 and 3. This was a bit frustrating since these are not yet published, and I have a nagging doubt that I might have retired by the time they get published. Amazon.com says March 14, 2021 for Volume 2, but I’ll believe that when it is in my letter box.

I didn’t like the advice to use structs rather than namespaces. This made me feel like I was back in 1996 and I thought that the arguments were rather contrarian. I appreciate that there are valid points in the 7 item list on page 316. However, I feel that using structs in this way is confusing for inexperienced programmers.

I don’t know how relevant this book will be in the short to medium term. C++ modules are likely to make a substantial change to the physical side of C++. Lakos does touch on this subject, and he is active in the standardization of the feature.

Website www.informit.com/store/large-scale-c-plus-plus-volume-i-process-and-architecture-9780201717068