关于#include

[geozhang]

在头文件中，如果#include少了编译时会出错，#include多了没事，

既然如此，我#include QT的所有模块，会怎样？

编译后的目标程序会很大？ 运行速度会很慢？请不要猜测，说明下内在机制是怎样的.

[MicroSky2813]

我有时临时就这样

#inclde<QtGui>
#inclde<QtCore>

这算是C++的问题了，编译后的程序肯定不会更大，也不会更慢，除非编译器太古怪了
这与编译器有关系，就像C++里的inlude<cstdio>然后你用下printf，实际程序里只加了printf的相关

原理用gcc来说了
g++ .cpp -o .o
然后g++ .o -o .exe
在.o这一步就会改连接的留个位置，改引进来的引进来一般加上优化是不会有额外的东西的


但在编译的时候会有一点点的慢

[我啃]

编译变慢，潜在的体积变大~

[cblcz]

引用 2 楼 kenmark 的回复:

编译变慢，潜在的体积变大~

好像是 google c++编程风格指南 中说到，要用哪个头文件就包含哪个，不要图省事

前几天在网上看到包含头文件要精确，而不是正确

[dext]

file 1

int main() {
    return 0;
}

release: 8383 bytes
debug: 8775 bytes

file 2

#include <iostream>
#include <cstdio>

int main() {
    return 0;
}

release: 8666 bytes
debug: 37006 bytes

事实证明 头文件越少，代码越小，因为头文件中可能有代码。
Ubuntu 9.10
GCC 4.4.1

[stilling2006]

要精确。

编译过程会慢，体积应该不会增大。

[geozhang]

从dext提供的数据看：
无头文件时：
release: 8383 bytes
debug: 8775 bytes

有头文件时：
release: 8666 bytes
debug: 37006 bytes

release几乎无变化，debug变化大，从8775bytes 巨增到37006bytes

结论：
说明包含多余的头文件，只会对编译，调试产生影响，编译过程会慢。而对最后发布的程序影响很少。

[拉卡尼休]

学C/C++应该学过预编译吧，这问题还用问