包含太多的头文件会增加源文件的大小吗？它也会增加可执行文件的大小吗？这些头文件会增加编译时间吗？例如，如果我在我的程序中添加这些头文件，它们会增加源文件或可执行文件的大小吗？
#include <stdio.h> #include "header1.h" #include "header2.h"
包含太多头文件的其他问题是什么？
l5tcr1uw1#
包含太多头文件会增加源文件的大小。如果在你的系统中，一个字母等于一个字节，那么增加#include <stdio.h>至少会使源代码文件增加18个字节。除非你使用的是20世纪80年代中期的计算机，否则这对你来说并不重要。它是否也会增加可执行文件的大小？不会。只有使用过的函数会增加可执行文件的大小。这些头文件是否会增加编译时间？一般来说是的，尽管编译器使用各种技巧，比如为自己的库使用“预编译头”。同样，这不是问题，除非你使用的是20世纪80年代的东西或者更糟的东西（比如Eclipse）。包含太多头文件的其他问题是什么？关于包含标头，你主要关心的是不要包含你不使用的东西。每个包含都会创建一个依赖项，也意味着更多的标识符和符号被添加到全局名称空间中。
#include <stdio.h>
webghufk2#
"#include <stdio.h>"
strlen("#include <stdio.h>");
#included
#defines
如果每个头文件都是必需的，那么就不需要太多。（关于maximum header file depth的注意事项）。但是，如果发现头文件是 * 不必要的 *，它是code bloat，请删除它。它会增加编译时间，因为每个头文件不管其中是否有任何有用的东西都必须被构建过程所查看。头文件增加了未来维护人员任务的复杂性和难度。有一个good post here更详细地讨论了这一点。此外，还讨论了头文件的this is a fun page。
ippsafx73#
头文件不应该产生任何额外的代码，除非它们设计得很糟糕，如果它们产生了额外的代码，并且你不止一次地包含它们，你可能会遇到重新定义的问题。这里的代码我指的是“机器代码”，也就是可执行代码。关于源代码，编译器最终会把源代码看作一个大的源代码，用#include指令替换文件的内容，所以添加更多的头文件会增加编译时间（因为表面上的源代码会更长）。所以应该避免包含不必要的文件。
1qczuiv04#
添加头文件会增加中间源文件的大小，考虑到包含的内容。现代编译器甚至可能不显式生成这个中间文件--它可能被吸收到整个编译过程中。这是编译器设计的问题。作为一个开发人员，除非你要求，否则你可能永远不会看到完全展开的文件（例如，gcc -E）。添加头文件并不一定会增加编译代码的大小--如果所有的头文件都包含is声明和常量定义，那么它们不会增加太多的大小。如果它们包含实际的代码--这并不是一个特别常见的做法--它们可能会对可执行文件的大小有一些小的影响。添加头文件可能会对编译时间产生一些影响，但实际上，这不是任何人都应该问的问题。如果你需要头文件，你就需要头文件。如果它会减慢编译速度，还有什么选择呢？不编译吗？如果问题是关于如何在头文件和源文件之间分配代码，以改进编译过程的某些方面，那么这是一个非常复杂的问题。如果问题是关于包含一堆你不使用的头文件会造成什么危害，那么现代编译器的答案是：从功能的Angular 来看，这是非常少的。然而，包含一些头文件会给读者一种印象，即源代码实际上使用了它声明的特性，这对可读性是不利的。你应该帮你未来的自己或你的同事一个忙，尽量不要包含没有使用的头文件。但是如果你需要它们，你就需要它们，没有必要太担心后果。
gcc -E
a64a0gku5#
包含太多的头文件是否会增加源文件的大小？源文件中的字符越多，源文件的大小就越大。但这只是关于#include指令本身，而不是头文件的内容--源文件不会被头文件的内容扩展。当你#include一个头文件时，编译器会在那个时间点读取它，但是源文件没有改变。所以，是的。它是否也会增加可执行文件的大小？取决于标头的内容。如果它们包含定义，则是。这些头文件是否会增加编译时间？从编译器读取和求值的内容越多，编译的时间就越长。包含太多头文件的其他问题是什么？如前所述，计算的时间可能会更长，因此头文件越多，编译速度就越慢。但是添加尽可能多的 * 有用的 * 头文件并没有错。只是不要添加不必要的头文件，这会减慢编译速度。
#include
5条答案
按热度按时间l5tcr1uw1#
包含太多头文件会增加源文件的大小。
如果在你的系统中，一个字母等于一个字节，那么增加
#include <stdio.h>至少会使源代码文件增加18个字节。除非你使用的是20世纪80年代中期的计算机，否则这对你来说并不重要。它是否也会增加可执行文件的大小？
不会。只有使用过的函数会增加可执行文件的大小。
这些头文件是否会增加编译时间？
一般来说是的，尽管编译器使用各种技巧，比如为自己的库使用“预编译头”。同样，这不是问题，除非你使用的是20世纪80年代的东西或者更糟的东西（比如Eclipse）。
包含太多头文件的其他问题是什么？
关于包含标头，你主要关心的是不要包含你不使用的东西。每个包含都会创建一个依赖项，也意味着更多的标识符和符号被添加到全局名称空间中。
webghufk2#
"#include <stdio.h>"会将源文件的物理大小精确地增加该语句中的字符数，例如”：strlen("#include <stdio.h>");字节。（并且，取决于OS如何分配file block size，它可以被OS视为额外的kByte。）然而更重要的是，在编译时，each 头文件#included的内容将有效地扩展到馈送到编译器的源代码中。#defines等，那么编译时间就是正常的编译时间。但如果你已经用3个必要的头文件编译了一段时间，并决定要添加一个新的库（它是相应的头文件。），那么无论如何，是的，下一次编译将比前一次编译花费更长的时间。如果每个头文件都是必需的，那么就不需要太多。（关于maximum header file depth的注意事项）。但是，如果发现头文件是 * 不必要的 *，它是code bloat，请删除它。它会增加编译时间，因为每个头文件不管其中是否有任何有用的东西都必须被构建过程所查看。头文件增加了未来维护人员任务的复杂性和难度。
有一个good post here更详细地讨论了这一点。
此外，还讨论了头文件的this is a fun page。
ippsafx73#
头文件不应该产生任何额外的代码，除非它们设计得很糟糕，如果它们产生了额外的代码，并且你不止一次地包含它们，你可能会遇到重新定义的问题。这里的代码我指的是“机器代码”，也就是可执行代码。
关于源代码，编译器最终会把源代码看作一个大的源代码，用#include指令替换文件的内容，所以添加更多的头文件会增加编译时间（因为表面上的源代码会更长）。所以应该避免包含不必要的文件。
1qczuiv04#
添加头文件会增加中间源文件的大小，考虑到包含的内容。现代编译器甚至可能不显式生成这个中间文件--它可能被吸收到整个编译过程中。这是编译器设计的问题。作为一个开发人员，除非你要求，否则你可能永远不会看到完全展开的文件（例如，
gcc -E）。添加头文件并不一定会增加编译代码的大小--如果所有的头文件都包含is声明和常量定义，那么它们不会增加太多的大小。如果它们包含实际的代码--这并不是一个特别常见的做法--它们可能会对可执行文件的大小有一些小的影响。
添加头文件可能会对编译时间产生一些影响，但实际上，这不是任何人都应该问的问题。如果你需要头文件，你就需要头文件。如果它会减慢编译速度，还有什么选择呢？不编译吗？
如果问题是关于如何在头文件和源文件之间分配代码，以改进编译过程的某些方面，那么这是一个非常复杂的问题。如果问题是关于包含一堆你不使用的头文件会造成什么危害，那么现代编译器的答案是：从功能的Angular 来看，这是非常少的。然而，包含一些头文件会给读者一种印象，即源代码实际上使用了它声明的特性，这对可读性是不利的。你应该帮你未来的自己或你的同事一个忙，尽量不要包含没有使用的头文件。但是如果你需要它们，你就需要它们，没有必要太担心后果。
a64a0gku5#
包含太多的头文件是否会增加源文件的大小？
源文件中的字符越多，源文件的大小就越大。
但这只是关于
#include指令本身，而不是头文件的内容--源文件不会被头文件的内容扩展。当你
#include一个头文件时，编译器会在那个时间点读取它，但是源文件没有改变。所以，是的。
它是否也会增加可执行文件的大小？
取决于标头的内容。如果它们包含定义，则是。
这些头文件是否会增加编译时间？
从编译器读取和求值的内容越多，编译的时间就越长。
包含太多头文件的其他问题是什么？
如前所述，计算的时间可能会更长，因此头文件越多，编译速度就越慢。但是添加尽可能多的 * 有用的 * 头文件并没有错。只是不要添加不必要的头文件，这会减慢编译速度。