Are unused includes harmful in C/C++?

C++

C++ Problem Overview


What are the negative consequences of unused includes?

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

C++ Solutions


Solution 1 - C++

  • 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.

Solution 2 - C++

They don't necessarily increase binary size, but will increase compile time.

Solution 3 - C++

The main problem is clutter. These are the three main aspects in which the clutter manifests:

  1. Visual pollution; while you are trying to figure other includes that you do need.

  2. Logical pollution; it is more likely to have collision of functions, more time to compile (it might be really small for a couple of includes, but if it becomes a "policy" to not cleaning up unneeded includes, it might become a significant hurdle).

  3. Dependency opacity; since there are more headers to analyze is it harder to determine the dependency cycles in your code. Knowing what are the dependencies in your code is crucial when your codebase grows to any significant level beyond the hobbyist level.

Solution 4 - C++

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.

Solution 5 - C++

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 http://www.boost.org/doc/libs/1_47_0/doc/html/foreach.html#foreach.introduction.making__literal_boost_foreach__literal__prettier">BOOST_FOREACH</a> 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 http://msdn.microsoft.com/en-us/library/7f0aews7.aspx">#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 http://sdl.beuc.net/sdl.wiki/SDL_CreateMutex">`SDL_CreateMutex`</a> 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...

Solution 6 - C++

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.

Solution 7 - C++

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

Solution 8 - C++

They represent clumsy design.

If you are not sure what to include and what not to include, it shows the developer had no idea what he was doing.

Include files are meant to be included only when the are need. It may not be that much of issue as the computer memory and speed is growing by leaps and bounds these days but it was once perhaps.

If an include is not needed but included anyhow, I would recommend to put a comment next to it saying why you included it. If a new developers get on to your code, he will have much appreciation for you, if you have done it the right way.

Solution 9 - C++

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

Solution 10 - C++

Yes, they can increase binary size because of extern unused variables.

//---- in unused includes ----
extern int /* or a big class */ unused_var;

//---- in third party library ----
int unused_var = 13;

Attributions

All content for this solution is sourced from the original question on Stackoverflow.

The content on this page is licensed under the Attribution-ShareAlike 4.0 International (CC BY-SA 4.0) license.

Content TypeOriginal AuthorOriginal Content on Stackoverflow
QuestionanioView Question on Stackoverflow
Solution 1 - C++mloskotView Answer on Stackoverflow
Solution 2 - C++David Rodríguez - dribeasView Answer on Stackoverflow
Solution 3 - C++lurscherView Answer on Stackoverflow
Solution 4 - C++user865927View Answer on Stackoverflow
Solution 5 - C++paercebalView Answer on Stackoverflow
Solution 6 - C++NPEView Answer on Stackoverflow
Solution 7 - C++FailedDevView Answer on Stackoverflow
Solution 8 - C++Hammad KhanView Answer on Stackoverflow
Solution 9 - C++user966379View Answer on Stackoverflow
Solution 10 - C++Amir SaniyanView Answer on Stackoverflow