Are unused includes harmful in C/C++?

Question

What are the negative consequences of unused includes?

I\'m aware they result in increased binary size (or do they?), anything else?

Answer 1

include means you are adding some more declarations. So when you are writing your own global function, you need to be carefull wheather that function is already declaerd in the header included.

Ex. if you write your own class auto_ptr{} without including "memory", it will work fine. but whenever you will include memory, compiler gives error as it already has been declared in memory header file

Answer 2

I'll assume the headers can all be considered as "sincere", that is, are not precisely written with the aim of sabotaging your code.

• It will usually slow the compilation (pre-compiled headers will mitigate this point)

• it implies dependencies where none really exist (this is a semantic errors, not an actual error)

• macros will pollute your code (mitigated by the prefixing of macros with namespace-like names, as in BOOST_FOREACH instead of FOREACH)

• an header could imply a link to another library. in some case, an unused header could ask the linker to link your code with an external library (see MSCV's #pragma comment(lib, "")). I believe a good linker would not keep the library's reference if it's not used (IIRC, MSVC's linker will not keep the reference of an unused library).

• a removed header is one less source of unexpected bugs. if you don't trust the header (some coders are better than others...), then removing it removes a risk (you won't like including an header changing the struct alignment of everything after it : the generated bugs are... illuminating...).

• an header's static variable declaration will pollute your code. Each static variable declaration will result in a global variable declared in your compiled source.

• C symbol names will pollute your code. The declarations in the header will pollute your global or struct namespace (and more probably, both, as structs are usually typedef-ed to bring their type into the global namespace). This is mitigated by libraries prefixing their symbols with some kind of "namespace name", like SDL_CreateMutex for SDL.

• non-namespaced C++ symbol names will pollute your code. For the same reasons above. The same goes for headers making wrong use of the using namespace statement. Now, correct C++ code will namespace its symbols. Yes, this means that you should usually not trust a C++ header declaring its symbols in the global namespace...

Answer 3

Whether or not they increase the binary size really depends on what's in them.

The main side-effect is probably the negative impact on compilation speed. Again, how big an impact depends on what's in them, how much and whether they include other headers.

Answer 4

Well for one leaving them there only prolong the compile time and adds unnecessary compilation dependencies.

Answer 5

• Increases compilation time (potentially serious issue)
• Pollutes global namespace.
• Potential clash of preprocessor names.
• If unused headers are included from third-party libraries, it may make such libraries unnecessarily maintained as dependencies.

Answer 6

Generally speaking, yes, it does cause some problems. Logically speaking, if you don't need it then don't include it.

• Any singletons declared as external in a header and defined in a source file will be included in your program. This obviously increases memory usage and possibly contributes to a performance overhead by causing one to access their page file more often (not much of a problem now, as singletons are usually small-to-medium in size and because most people I know have 6+ GB of RAM).

• Compilation time is increased, and for large commercial projects where one compiles often, this can cause a loss of money. It might only add a few seconds on to your total time, but multiply that by the several hundred compiles or so you might need to test and debug and you've got a huge waste of time which thus translates into a loss in profit.

• The more headers you have, the higher the chance that you may have a prepossessing collision with a macro you defined in your program or another header. This can be avoided via correct use of namespaces but it's still such a hassle to find. Again, lost profit.

• Contributes to code bloat (longer files and thus more to read) and can majorly increase the number of results you find in your IDE's auto complete tool (some people are religiously against these tools, but they do increase productivity to an extent).

• You can accidentally link other external libraries into your program without even knowing it.

• You may inadvertently cause the end of the world by doing this.