76

What are the negative consequences of unused includes?

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

Prince John Wesley
  • 62,492
  • 12
  • 87
  • 94
anio
  • 8,903
  • 7
  • 35
  • 53
  • 5
    For trimming includes ["Header Hero"](http://altdevblogaday.com/2011/10/08/caring-by-sharing-header-hero/) – user786653 Oct 27 '11 at 16:41
  • 4
    As a side question: does anyone know of any tools for automatically removing unused includes? – Giorgio Oct 27 '11 at 19:17

10 Answers10

85
  • 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.
mloskot
  • 37,086
  • 11
  • 109
  • 136
  • 2
    Potentially serious issue? I also believe so, but I have been laughed at when I posted a question about this. Somehow it seems to be a widely accepted opinion that unneeded includes are not a serious problem. – Giorgio Oct 27 '11 at 18:44
  • I assumed potentially serious because for some it might be not necessarily serious issue. Depends on personal or project team preferences and priorities. – mloskot Oct 27 '11 at 18:54
  • I interpreted your answer in the following sense: unused includes can perceivably increase compilation time. So it can become a problem and you have to be careful. With a good discipline you can avoid or reduce unused includes to a minimum. – Giorgio Oct 27 '11 at 19:01
  • Giorgio, yes, this is what meant as potential ("it can become a problem"). – mloskot Oct 27 '11 at 19:13
  • 1
    Specifically I think this issue tends to get serious on large projects when there are hundreds or thousands of needless header files. It might not hurt to talk about things like include guards or precompiled headers in this answer. – mwd Nov 01 '11 at 18:43
  • *Potential pollution of global namespace – Trevor Hickey Nov 12 '12 at 05:24
  • @Xploit It's there, second bullet – mloskot Nov 12 '12 at 10:44
32

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

David Rodríguez - dribeas
  • 204,818
  • 23
  • 294
  • 489
23

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.

Justin R.
  • 23,435
  • 23
  • 108
  • 157
lurscher
  • 25,930
  • 29
  • 122
  • 185
16

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.

8

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

paercebal
  • 81,378
  • 38
  • 130
  • 159
6

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.

NPE
  • 486,780
  • 108
  • 951
  • 1,012
2

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

FailedDev
  • 26,680
  • 9
  • 53
  • 73
2

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.

TheTechGuy
  • 16,560
  • 16
  • 115
  • 136
0

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

user966379
  • 2,823
  • 3
  • 24
  • 30
  • No, it won't, because `` will declare a std::auto_ptr. This is the whole point of namespaces in C++. A pure C example would be a better example... – paercebal Oct 28 '11 at 09:48
  • 1
    `you are redefining class auto_ptr so it will give error` : You didn't understand. ``'s `auto_ptr` is protected by the namespace `std`, so you could write your own `auto_ptr` class in the global namespace, or even better, in your own namespace, and it would not conflict with `std::auto_ptr` because you are protected by C++ namespaces which make both classes completely distinct. So, no compilation error. – paercebal Oct 28 '11 at 13:20
0

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;
Amir Saniyan
  • 13,014
  • 20
  • 92
  • 137