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

Answer 1

Yes, in some ways, the book is a little dated and some of it is C++ specific. Nonetheless, it offers a lot of useful advice about dealing with complexity and coupling in large programs, and most of his advice applies to any object-oriented language. I also found it very readable.

If you can track down a copy, I'm sure you'll find it worth reading. It's in my top ten list of programming books.

Answer 2

It is an excellent book and an important one from a historical point of view.

Note that to implement the practices described in the book, you need considerable discipline and agreement within the team. Here are a few things to note:

1. Lakos has precise definitions for what he calls "components" and "packages". These are key for large scale design. However, they require adherence to conventions for how source and header files are named and the sequence in which they are included. It is a shame that most people (including those who quote Lakos) rarely follow these conventions.

2. The book is all about C++ but the concepts are more widely applicable. However, because C++ is such a complex language, a large part of the book is teaching you how to use C++ effectively. If you can get past that, you can actually find it useful even if you use other languages.

3. Some of the prescriptions such as on the use of "name spaces" maybe considered controversial now. Many believe that name spaces should be used in a limited way in C++.

Answer 3

Is “Large-Scale C++ Software Design” by John Lakos a mind-provoking (but usually overlooked) gem?

Yes.

Answer 4

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.

Answer 5

I read it a long time ago, but I remember getting quite a lot from it; though as MadKeithV points out, that may just have been that I knew less then ;)

Certainly from a "how do I reduce how long this takes to build" perspective it's has lots of useful stuff, especially around reducing compile time dependencies, though possibly some of it is no longer relevant, or even possible, given how much templates are used these days.

And no, you can't have my copy either :)

Answer 6

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.