#include affects program size?

When my cpp file uses #include to add some header, does the size of my last program increase? The header is not considered as compilation units, but the contents of the header file are added to the actual source file by the preprocessor, so will it affect the size of the output file (exe or dll)?

Edit: I forgot to mention that this is not about templates / built-in functions. I had in mind what would happen if I put #include in a header that did not have any detail about the implementation of functions. Thanks

+4
source share
8 answers

You explained that:

[No title] templates / built-in functions ... does not have any implementation details.

Generally speaking, no, adding a header file will not affect the size of the program.

You can check it out. Take the program that is already creating and check the size of the executable file. Then go into each .cpp file and include the standard C or C ++ header file, which is not really needed in this file. Build the program and check the size of the executable file again - it should be the same size as before.

In general, the only things that affect the size of an executable are those that cause the compiler to generate different amounts of code, initialize a global / static variable, or use DLLs / shared libraries. And even then, if any such elements are not needed for the program to work, most modern linkers will drop these things.

Thus, including header files containing only objects such as function prototypes, class / structure definitions without embedded links, and enumeration definitions should not change anything.

However, there are, of course, exceptions. Here are a few.

One of them, if you have an inexperienced linker. Then, if you add a header file that generates things that the program really does not need, and the linker does not throw them away, the size of the executable will be bloated. (Some people intentionally create linkers this way because link time can become insanely fast.)

Many times, adding a header file that adds or modifies the definition of a preprocessor symbol will change what the compiler generates. For example, assert.h (or cassert) defines an assert () macro. If you include the header file in the .c / .cpp file, which changes the definition of the NDEBUG preprocessor symbol, it will change whether assert () will use any code and, therefore, change the size of the executable file.

In addition, adding a header file that changes the compiler options will change the size of the executable file. For example, many compilers allow you to modify the standard "packaging" of structures through something like the line of the #pragma package. Therefore, if you add a header file that changes the packaging structure in the .c / .cpp file, the compiler will create different code to work with the structures and, therefore, change the size of the executable file.

And as someone else remarked, when you are dealing with Visual C ++ / Visual Studio, all bets are disabled. Microsoft has, letโ€™s say, a unique perspective around their development tools that are not used by people writing compiler systems on other platforms.

+6
source

It depends on the content and how your compiler is being implemented. It is possible that if you do not use anything in the header, your compiler will be smart enough not to add it to your executable file.

However, I would not count on it. I know that back in VC ++ for 6 days, we found that meerly #including Windows.h added 64K to exccecutable for every source file that did this.

+10
source

When using modern compilers, files only affect the size of binary files if they contain static data, or if you use the normal or built-in function defined in them.

+1
source

Yes, because, for example, built-in functions can be defined in header files, and the code of these built-in functions, of course, will be added to your program code when these functions are called. Template instances of your program code will also be added.

0
source

And you can also define global variables in header files (although I would not recommend it). If you do this, you must surround them with # ifdef / # end blocks so that they are not defined in more than one compilation unit (or the linker will complain). In any case, this will increase the size of the program.

0
source

For headings that are fully declarative (usually they should be), no. However, the pre-processor and compiler take time to parse the headers, so headers can increase compilation time; especially large and deeply nested, for example, so some compilers use โ€œprecompiled headersโ€.

Even inline and boilerplate code does not directly increase code size. If the template is never created or the built-in function is not called, the code will not be generated. However, if it is called / instantiated, the size of the code can grow rapidly. If the compiler really embeds the code (the compiler is not required to do this, and most of them are not delayed), code duplication can be significant. Even if it is not a truly built-in compiler, it is still created statically in every object module that refers to it - an intelligent linker is required to remove duplicates, and this is not specified - if individual object files were compiled with different parameters, the built-in code from that the same source cannot generate identical code in each object file, therefore it is not even duplicated. In the case of templates and for each type a separate instance will be created.

0
source

Remember that #define clauses can inflate code at compile time into a huge but functional compiled file.

0
source

It is good practice to limit the #includes in the file to those that are needed. Besides affecting the size of the executable file, the presence of additional #includes will lead to a larger list of compile-time dependencies, which will increase build time if you usually change the header file with the #include extension.

0
source

All Articles