One of the reasons is that any reasonably interesting C++ program has lots of classes, and quite frequently, each class is in a separate file. Which actually means two files, one for the .cpp and another for the .h.

One implication of this is that if one of the header files is changed, any cpp file that uses that header file or cpp file that uses a header that uses the changed header is going to need recompilation.

Further, lots more is happening during compile for C++ as compared to Java, where more happens at run-time. Depending on their extent of usage, templates can consume measurable compile time. Extensive optimization can cause measurable increase in compile time.

Also contrast the compile time you get with go, which is ridiculously faster than C++ when measured by the edit-compile-link-run cycle.

I am now of the opinion that the C++ compilation model is broken, or more charitably, has been shown to not have learned from the compilation models of the following languages:

* python * ruby * go * java and other jvm uses such as clojure * and many others

despite what Herb says about how modern c++ is.

I'm going to assume you mean that when you update a project, it takes a long time to recompile-- as opposed to the time it takes to compile from scratch (although I would still be surprised if Java is faster on a comparable-sized project).

You may have an include file that gets touched/changed a lot, and that shows up (directly or indirectly) in most of your project files. Have a look at your dependency tree and see if anything jumps out at you. Alternately, you can "touch" a few files at a time manually, re-build, and try to track down a culprit that way.

Also, take a look at John Lakos' "Large-Scale C++ Software Design", which offers metrics and design guides for reducing dependencies among files in a project.

Assuming you have no way to get around each source file including lots of headers, many C/C++ build tools offer some kind of "pre-compiled header" option, that you might look into.

Finally, check to see whether you're doing a very aggressive "release" build, with lots of inter-procedural optimizations enabled. I find IPO at the link stage takes a very long time. So compare your debug build options against your release build options, and think about what the timing differences tell you.

My experience is that slow-compiling projects tend to have bloated header files. The C/C++ pre-processor needs to apply #define's and friends before it touches source files. Java compilers don't suffer from this problem because the Java spec doesn't have support for header files.

There are a few factors:

* Massive includes. Every compilation unit ends up including many header files. Most of these header files include more header files, often ones already included. If a header file has previously been included, it must be included a second time as C++ allows the meaning of including a file to differ each inclusion. This results in a vast amount of necessary preprocessing.

* Compiling the same code multiple times. Every compilation unit must generate code for every template it uses, even if other compilation units are generating the same code. Only at link time are the multiple instantiations of the same code collapsed. As the STL is a massive blob of templates this is a frequent issue!

The problem is simply that C++ is a MUCH more complicated language than Java. Just compare the grammars and look at all the crazy ambiguities of C++.