3

Does including too many header files increase the size of the source file. Does it also increase the size of executable? Do these header files increase the compilation time?

For example if i add these header files in my program do they increase of size of source file or executable file or both?

#include <stdio.h>
#include "header1.h"
#include "header2.h"

What are the other problems of including too many header files?

Anonymous
  • 75
  • 1
  • 8
  • 1: unclear what you're asking, but probably yes, because each time you add `#include ` the size of your source file is obviously increased. 2: maybe, it depends on the content iof header files. 3: probably yes, it also depends on the size and the complexity of the header files. 4: what is "too many" ? – Jabberwocky Sep 16 '20 at 13:19
  • 1
    Whatever is the correct answer. Don't merge your small headers to a huge header for avoiding count of #include lines. – SKi Sep 16 '20 at 14:11

5 Answers5

3

Does including too many header files increase the size of the source file.

It increases with as many letters as you type. So if 1 letter is 1 byte on your system, then adding #include <stdio.h> increases the source code file size by at least 18 bytes. This shouldn't matter to you unless you are using a computer from the mid-1980s.

Does it also increase the size of executable?

No. Only used functions increase the size of the executable.

Do these header files increase the compilation time?

Generally yes, though compilers use various tricks such as "precompiled headers" for its own libraries. Again, this isn't a problem unless you are using 1980s stuff or worse (such as Eclipse).

What are the other problems of including too many header files?

Your main concern about including headers should be to not include stuff that you don't use. Every include creates a dependency, and also means more identifiers and symbols added to the global namespace.

Lundin
  • 195,001
  • 40
  • 254
  • 396
  • Eclipse or any other IDE have nothing to do with compilation times. – the busybee Sep 16 '20 at 13:25
  • Not only used functions will increase the executable size, it depends on the compilation unit of the library you are linking with and the parameters/capabilities the compiler. If you use a function that is in the same compilation unit of an unused one, the final executable will most probably contain both. – Pablo Yaggi Sep 16 '20 at 13:26
  • You might like to add that the standard defines an implementation defined limit of at least 15 levels of inclusions. The total number of inclusions is not limited. – the busybee Sep 16 '20 at 13:29
  • Disagree on the compile time increase is not a problem claim. The problem grows exponentially with project size since all the header files you include often include a dozen other header files. For a project with 5 or less programmers, it does not matter but for large project it matters a lot. – 12431234123412341234123 Sep 16 '20 at 14:00
  • @thebusybee Tell that to Eclipse. – Lundin Sep 16 '20 at 14:01
  • @12431234123412341234123 Since you can include something like windows.h, which in turn includes countless other headers, yet compile within seconds, I think it's a non-issue. Let the tool chain handle it, which it is evidently is perfectly able to do. If you compile remotely across LAN or VPN etc that's another story. – Lundin Sep 16 '20 at 14:05
  • @PabloYaggi Only if you are using some pre-built library, then indeed that's the case. That's mostly a specific PC programming issue though. – Lundin Sep 16 '20 at 14:08
  • So if the header only contain the function declarations (so it can know the function declaration) but how would the compiler know the function definition of a built in function like `printf()` or `scanf()` – Anonymous Sep 16 '20 at 14:13
  • @thebusybee Indeed! It shouldn't be possible. For your benefit, I will launch one of the many Eclipse hellspawns present on my computer (and go grab a cup of coffee). Notably, it is missing an option called "compile", there is only "build". Aha, we might be on to something here! To build this project I picked from scratch takes approximately 20 seconds, compared to building the same project from scratch in a different IDE, where it takes approximately 0 seconds. Not counting the time it takes for Eclipse to check for updates. – Lundin Sep 16 '20 at 14:19
  • @Lundin I do not know how large the include tree of `windows.h` is and how it compared to something like the include tree for Linux. But seconds is a long time, think about a project with 1000 source files, when every source file takes 3s for only the includes, you lost already 50min of cpu time just for including. – 12431234123412341234123 Sep 16 '20 at 14:35
  • @12431234123412341234123 Admittedly the largest project I was ever part of had something around 2 million LoC and maybe 300-400 files plus whatever windows.h and misc other libraries dragged in. Building the whole thing was slow, a couple of minutes. But you don't make a complete build that often. – Lundin Sep 16 '20 at 15:25
  • Why do the size only be increased by `strlen("#include ");` bytes? I read that the compiler will replace the header files with all the code present in the respective header files. – Anonymous Sep 16 '20 at 15:49
  • Well, the question was not how long a specific or any IDE needs to scan the sources, build an index, generate automatically a Makefile, and finally call the tools. The question was about compile time. You totally miss the point here, but we know you for bashing Eclipse. ;-) – the busybee Sep 17 '20 at 06:11
3

Does including too many header files increase the size of the source file.

Yes, For each additional character added to a source file, for example "#include <stdio.h>" increases the physical size of the source file precisely by the number of characters in that statement, eg": strlen("#include <stdio.h>"); bytes. (and, depending on how OS allocates file block size, it could be seen by the OS as an extra kByte.) More importantly though, at compile time the contents of each header file #included will effectively be expanded into source code that is fed to the compiler.

Does it also increase the size of executable?

Yes/No/Possibly. Depending on what is actually used in the header file. Optimizing compilers can exclude whatever is not needed in an executable. If nothing is used, there will no additional size to the executable. There will however be additional work done during compile-time because even if there is nothing useful in the header file, compiler does not know this until it is processed.

Do these header files increase the compilation time?

Compared to what? i.e. If there are, within a header file, necessary components to allow a build to occur, i.e. by containing prototypes of functions, #defines, etc, then compile time is just normal compile time. But if you have been compiling with say 3 necessary header files for awhile, and decide that you want to add a new library (and it's corresponding header file.), then by all means, yes, the next compile will take a little longer than those previous.

What are the other problems of including too many header files?

Too many?. If each and every header file is necessary, then there are not too many. (with this caveat about maximum header file depth.) However, if a header file is found to be unnecessary, its code bloat, get rid of it. It adds to compile time, as each header file regardless of whether there is anything useful in it has to be looked at by the build process. Even worse unnecessary header files add complexity and difficulty to the tasks of future maintainers.

There is a good post here discussing this in more detail.

Additionally, this is a fun page that also discusses header files.

ryyker
  • 22,849
  • 3
  • 43
  • 87
  • Why do the size only be increased by `strlen("#include ");` bytes? I read that the compiler will replace the header files with all the code present in the respective header files. – Anonymous Sep 16 '20 at 15:48
  • @Anonymous - That particular question is worded _size of source file_, so literally, the size of the _source_ file is only affected by the byte count of its content (i.e. the number of characters contained in the file) and the OS handling of `file` block memory allocation. (some OS allocate file size by blocks, 1 kByte per allocation, so even a single character results in 1 kByte file block allocation size, the next 999 characters are free (no more blocks allocated), but one more ( now 1001 bytes) will result in an additional 1 kByte block file size. (note, physical file size is still... – ryyker Sep 16 '20 at 16:01
  • @Anonymous - ...measured by the number of bytes in the file.) So, all that to say that given, `int len = strlen("#include ")` the file physical size is changed only by `len` bytes by adding this statement. Note though, the effect that including a header file has on subsequent objects, such as the resulting binary code, or the work that the volume of content that a compiler must traverse however is greatly affected. – ryyker Sep 16 '20 at 16:02
2

Header files should not produce any extra code unless they are poorly designed, an d you will probably encounter redefinition problems if they do and you include them more than once. By code here I mean "machine code", that is executable code.
About the source code, the compiler ultimately sees the source code as one big source code with the #include directives replaced by the content of the file, so adding more header files will increase the compile time (as the apparent source code will be longer). So including unnesessary files should be avoided.

Pablo Yaggi
  • 1,061
  • 5
  • 14
1

Adding header files will increase the size of the intermediate source file, taking into account the inclusions. Modern compilers may not even generate this intermediate file explicitly -- it may be absorbed into the overall compilation process. This is a matter of compiler design. As a developer, you probably won't ever see the fully-expanded file unless you ask for it (e.g., gcc -E).

Adding header files will not necessarily increase the size of the compiled code -- if all the headers contain is declarations and constant definitions, they won't increase the size much, if at all. If they contain actual code -- which isn't a particularly common practice -- they might have some small effect on the executable size.

Adding header files will probably have some effect on the compilation time but, really, this isn't a question anybody should be asking. If you need the headers, you need the headers. If it slows down compilation, what's the alternative? Don't compile?

If the question is really about how to distribute code between headers and source files, so as to improve some aspect of the build process, then that's a very complicated question to answer. If the question is about what harm is done by including a bunch of headers you don't use, the answer with modern compilers is: very little, from a functional perspective. However, including some header gives the reader the impression that the source actually uses the features it declares, and that's bad for readability. You should do your future self, or your colleagues, a favour and try not to include headers that aren't used. But if you need them, you need them, and there's little point worry about the consequences too much,

Kevin Boone
  • 4,092
  • 1
  • 11
  • 15
  • "If it slows down compilation, what's the alternative?" Forward declaration (only for `struct`, `enum` and so on, not for functions), to avoid exponential grow of compile time, and with that not include other headers from the same project in header files. – 12431234123412341234123 Sep 16 '20 at 14:06
  • Sure, you can cherry-pick declarations from headers and put them into sources. It's irritating, and potentially a bear for long-term maintenance, but it's certainly possible. But in what circumstances would it actually be practicable? – Kevin Boone Sep 16 '20 at 14:09
  • "from headers and put them into sources" No, from headers to other headers. Forward declaration means not define the `struct` or `enum`, only declare that such a `struct` or `enum` exist. – 12431234123412341234123 Sep 16 '20 at 14:20
  • I concede there are things you can do if you're actually _writing_ the headers. I'm not sure that's relevant to the question, though. – Kevin Boone Sep 16 '20 at 14:22
1

Does including too many header files increase the size of the source file?

The more characters in the source file, the more size has the source file.

But it's only about the #include directives itself. Not the content of header files - the source file doesn't get expanded by the content of the headers.

When you #include a header, the compiler gets known about to read it at that point of time, but the source file isn't changed.

So, yes.

Does it also increase the size of executable?

Depends on the content of the headers. If they contain definitions then yes.

Do these header files increase the compilation time?

The more to read and evaluate from the compiler, the longer the time to compile. So yes.

What are the other problems of including too many header files?

As said before, the time to evaluate might take longer and thus the more header files, the slower the compilation. But there is nothing wrong to add as much useful headers as you like. Just don't add unnecessary headers, which slow down the compilation.

RobertS supports Monica Cellio
  • 14,524
  • 7
  • 33
  • 80