Is reducing number of cpp translation units a good idea?

Question

I find that if there are a lot of classes the compilation time is dramatically increased when I use one *.h and one *.cpp file per class. I already use precompiled headers and incremental linking, but still the compile time is very long (yes I use boost ;)

So I came up with the following trick:

• defined *.cpp files as non-compilable
• defined *.cxx files as compilable
• added one *.cxx file per application module, and #included all the *.cpp files of this module in it.

So instead of 100+ translation units I ended up with only 8 translation units. The compile time became 4-5 times shorter.

The downsides are that you have to manually include all the *.cpp files (but it's not really a maintenance nightmare since if you forget to include something the linker will remind you), and that some VS IDE conveniences are not working with this scheme, e.g. Go To/ Move to Implementation etc.

So the question is, is having lots of cpp translation units really the only true way? Is my trick a known pattern, or maybe I'm missing something? Thanks!

Answer 1

The concept is called unity build