Using libraries in C++ is simple. You just do #include<libname> and all necessary definitions appear in your source file.
But what is the cost of this single line of code?
Quite a lot, it turns out. Measuring the effect is straightforward. Gcc has a compiler flag -E, which only runs the preprocessor on the given source file. The cost of an include can be measured by writing a source file that has only one command: #include<filename>. The amount of lines in the resulting file tells how much code the compiler needs to parse in order to use the library.
Here is a table with measurements. They were run on a regular desktop PC with 4 GB of RAM and an SSD disk. The tests were run several times to insure that everything was in cache. The machine was running Ubuntu 12/10 64 bit and the compiler was gcc.
Header LOC Time map 8751 0.02 unordered_map 9728 0.03 vector 9964 0.02 Python.h 11577 0.05 string 15791 0.07 memory 17339 0.04 sigc++/sigc++.h 21900 0.05 boost/regex.h 22285 0.06 iostream 23496 0.06 unity/unity.h 28254 0.14 xapian.h 36023 0.08 algorithm 40628 0.12 gtk/gtk.h 52379 0.26 gtest/gtest.h 53588 0.12 boost/proto/proto.hpp 78000 0.63 gmock/gmock.h 82021 0.18 QtCore/QtCore 82090 0.22 QtWebKit/QtWebKit 95498 0.23 QtGui/QtGui 116006 0.29 boost/python.hpp 132158 3.41 Nux/Nux.h 158429 0.71
It should be noted that the elapsed time is only the amount it takes to run the code through the preprocessor. This is relatively simple compared to parsing the code and generating the corresponding machine instructions. I ran the test with Clang as well and the times were roughly similar.
Even the most common headers such as vector add almost 10k lines of code whenever they are included. This is quite a lot more than most source files that use them. On the other end of the spectrum is stuff like Boost.Python, which takes over three seconds to include. An interesting question is why it is so much slower than Nux, even though it has less code.
This is the main reason why spurious includes need to be eliminated. Simply having include directives causes massive loss of time, even if the features in question are never used. Placing a slow include in a much used header file can cause massive slowdowns. So if you could go ahead and not do that, that would be great.