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

Question

Reading the reviews at Amazon and ACCU suggests that John Lakos' book, Large-Scale C++ Software Design may be the Rosetta Stone for modularization.

At the same time, the book seems to be really rare: not many have ever read it, and no pirate electronic copies are floating around.

So, what do you think?

Answer 1

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.

Answer 2

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:)

Answer 3

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 ;^)

Answer 4

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.

Answer 5

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 6

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

Yes.

Answer 7

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 8

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 9

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 :)