我正在阅读 Herb Sutter 的 More Exceptional C++
关于前向声明的第 37 项说:
Never
#include
a header when a forward declaration will suffice. Prefer to#include
only<iosfwd>
when the complete definition of a stream is not needed.
我还听到了很多关于只包含编译单元所需的头文件以减少依赖关系的建议。
我完全理解为什么这应该适用于 project header ,但我不太明白为什么包含不必要的 standard header 是不好的。
例如我做这样的事情:
//standard_library.h
#ifndef STANDARD_LIBRARY
#define STANDARD_LIBRARY
#include <iostream>
#include <chrono>
#include <thread>
...
// Everything I need in the project
#endif
并在任何地方都包含这个单一的标题,我需要来自 std
的东西
我能想到的问题是:
- 不需要在 std 命名空间中的 C 库函数污染命名空间。
- 编译时间变慢
但到目前为止,我在 1. 方面没有遇到重大问题。几乎所有东西都在 std 命名空间中。我也不完全理解为什么 2. 必然是一个重大问题。标准标题很少更改。据我所知,编译器可以预编译它们。对于模板,只有在我需要它们时才会实例化(编译)它们。
还有好处:
- 少打字
- 少读书
- 不太清楚我需要哪些 header 以及某个函数在哪个 header 中
我是一个没有大型项目经验的初学者程序员,我真诚地想弄清楚这一点,所以请怜悯我。
最佳答案
另外
- 命名空间污染
- 编译时间(虽然可以通过预编译的头文件减少,但它会伤害那些编译一次大型项目的人,因为他们实际上想要使用它,而不是开发 - 你也想考虑偶尔需要的重建)<
您将“更少弄清楚我需要哪些 header 以及某个函数在哪个 header 中”命名为一个好处。我同意这对于设计良好的库和头文件来说是正确的。
然而,在实践中,我遇到了一些错误(至少在使用 MFC/ATL 时),这些错误可以通过找出正确的包含顺序来解决。另一方面,有一天您想解决一个问题,该问题使您穿越包含的 header - 现在想象您正在查看大量与您的代码文件无关的 header 文件。
我的结论是:如果您以后必须维护一个大型项目,那么通过包含一堆不必要的标题所节省的时间并没有返回。您在开始包含任何标题之前投入的时间越多,之后您的安全时间就越多 - 但主要是在没有真正意识到它的情况下。
关于c++ - 为什么不总是包含所有标准标题?,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/16830134/