Your thoughts on "Large Scale C++ Software Design" [closed]

Question

I've read it, and consider it a very useful book on some practical issues with large C++ projects. If you have already read a lot about C++, and know a bit about physical design and its implications, you may not find that much which is terribly "new" in this book.

On the other hand, if your build takes 4 hours, and you don't know how to whittle it down, get a copy, read it, and take it all in.

You'll start writing physically better code quite quickly.

[Edit] If you want to start somewhere, and can't immediately get a hold of the book, I found the Games From Within series on physical structure useful even after reading Large Scale C++ design.

Interestingly, "More C++ Gems" contains a shortened (to 88(!) pages) version of Lakos' book, which can also be browsed (fully, I believe, as it belongs to the first half of the book) online at Google books.

So, enjoy everyone interested:)

Lakos used to work for Mentor Graphics, who makes EDA software. He was involved in building EDA software in C++, where they wanted to use C++ efficiently ('no more than 5% overhead over C code') and sort out how to build software on early workstations that really would take a long time to compile a large C++ application.

The book is quite a good read - it discusses a wide variety of topics, and Lakos really did know his stuff. He really comes from a background of having to get efficient code out of a C++ compiler, as well as how to set up a C++ program so it is maintainable and compiles and links reasonably quickly.

I think that Lakos has a lot of insight, and I would recommend that you read it. However, it is 'trad' C++ from a time before features like templates were widely available. My copy is not for sale ;^)

I thought the book was a good read back in the late 1990s. It was out of date back then, now about as relevant as telephone book from the 1950s.

I worked with Lakos for several years where he tried to implement these ideas. I also had my modern C++ project I built of about 2000 source files-- large scale enough, and I've built a few more since. Build times are easily reduced by parallel distributed builds, using programs like icecream. Every complier will cache opened headers-- only by doing something really outrageous any modern build tool like scons will scale to thousands of translation units without doing anything really special, with build times, including tests, takes a couple minutes from clean.

Limiting your libraries interface to a few "vocabulary types" (not the same sence as the OO concept, he means just use Int, float, string, char, and a couple of other I don't recall) is extremely poor advice to scale anything. Your build is going to be looking for a type mismatch, you don't want this at runtime just to make it easier to write a make file.

And that's largely the gist of the book-- how do I write C++ in order that it works with tools from 1993? Additionally, the Mentor Graphic project the book describes was a disaster from all accounts. Even the book itself alludes to that.

Large Scale C++ is delivered in source code form-- these are the "physical dependencies," not link libraries (and the book never mentions other more important dependencies like databases, sockets, processor architecture, etc.).

The book is full of ideas that sound good, but there are much better ways to scale up in practice. If you want to study large C++ libraries, take a look at Boost or Xerces and see what they did. They really are implementing large projects, not writing about them.

It's a little out of date (in fact it was out of date when it was written). If I recall correctly, a lot of it was about reducing dependencies which you would probably do now with templates.

Although that's probably one of the lessons to learn on large scale projects, you aren't usually using cutting-edge features and tools.