Basic:

C++ Primer

Effective C++

Effective STL





Advanced:

More Effective C++

C++ Coding Standards: 101 Rules

C++ Templates The Complete Guide

Large Scale C++ Design

Taking a lot of care with regard to what needs to be included where can help. In some cases, you can just give a forward declaration of a class rather than including a header for it if you are just shuffling pointers to it around. In other cases, you can migrate a lot of implementation details using a 'PIMPL' style so only the public facing API is in the headers that get included. Make sure one header doesn't need to include a chain of 100 other headers for dependencies. Be careful with template stuff. Avoid putting templates in headers such that they wind up being recompiled in every source file. You can do explicit template instantiation for the specific types that you need, and you'll only have to compile them once. Divide the project into several small dynamic libraries, so you only have to build one lib at a time instead of the whole project.

I've heard good things about this book, but my build times aren't yet slow enough to give me time to read it. :) http://www.amazon.com/Large-Scale-Software-Design-John-Lakos/dp/0201633620

An interesting but brief article. I disagree with the premise that compilation is slow, I find it quick even with hundreds or thousands of source files. When optimizing build speed, look to PCH, forward declarations, better organization, and finally interfaces and pimpl if you're really desperate.

I suggest Large-Scale C++ Software Design by Lakos for more information.

Edit: Of course C++ compilation is a lot slower than some languages, but ~5 minutes to rebuild 1000 files is pretty reasonable.

Yes, every header file should include all other headers that it needs otherwise you will have a nightmare keeping track of include order dependencies. In order to speed up compile times you will want to put include guard ifdefs around the #include directive, not just inside.

So:

foo.h:

ifndef _FOO_H

    #define _FOO_H<br />

ifndef _BAR_H

    #include &amp;lt;bar.h&amp;gt;<br />
    #endif<br />

...

endif

bar.h:

ifndef _BAR_H

    #define _BAR_H<br />
    ...<br />
    #endif<br />

IIRC this is as recommended in Lakos' book: http://www.amazon.com/Large-Scale-Software-Design-John-Lakos/dp/0201633620

The Pragmatic Programmer is in my opinion the best book on "etiquette". My first boss in the games industry bought it for me and told me to read and absorb it.

Large Scale Software Design was the book I read about large scale structure, but I think it's kind of out dated if you ask me.

The hardest part in learning haskell is unlearning all the stuff you learned before and realizing that you are not just learning a new syntax over old concepts. Know that you are starting from scratch.

The second hardest part is once you have learned the basic concepts, is how do I put everything together. I feel this is where most of the books and online materials fall a bit short. There is no book called "Large Scale Purely Functional Software Design" yet (such as Large-Scale C++ Software Design).

Next time you're doing step 3 read this book which might help you cut down on compile times.

Depending on what you're doing and how you're organized, you've got a couple options.

There are, as you've been told in the SO question, a couple commercial solutions. One that wasn't mentioned was ElectricAccelerator, which is also supposed to be a good solution. I believe they have a free/limited trial version these days.

There's also the Team Foundation Server/Build, which is Microsoft's approach to the problem. I've never had cause to use it myself, since it's an all-in on Microsoft tech, which simply isn't tenable for my use-case.

That said, in my experience, a lot of slow builds can be drastically improved simply by organizational changes and good modularity in the code. If your problems are like those I've solved for my current and previous teams, you're likely building your entire stack in a single solution, whether you need to or not. If you can find the pieces that are library-izable and break them out so they're not being built every time, you can get huge gains on the normal day-to-day build times.

I'd highly recommend reading John Lakos's book Large Scale C++ Software Design. It's a little dated, but loaded with still-relevant techniques and information.

I've spent a lot of time fixing builds for myself and others, so feel free to ask questions.

His book is good too on this sort of topic. (I think, anyway.) There are also some expensive videos as part of a workshop.

I worked on the Windows operating system and Internet Explorer at various points in my career. With very large projects like those, even normally trivial problems become significant engineering tasks when doing so at those scales. Just compiling the core library of IE (allocators, text handling, dom, etc) could take half an hour, so you really came to appreciate incremental builds.

To get a sense of the scale of such problems, I might recommend the book Large Scale C++ Design. I remember finding the book very dry, but in the author's defense, it's a very dry problem space.