9.5 Afternotes
9.5 后记
The organization of source code in header files and CPP files is a practical consequence of various incarnations of the one-definition rule or ODR. An extensive discussion of this rule is presented in Appendix A.
将源代码分为头文件和CPP文件是在实践中遵守唯一定义法则(one-definition rule,ODR)的体现。附录A对这一规则进行了广泛的讨论。
The inclusion model is a pragmatic answer dictated largely by existing practice in C++ compiler implementations. However, the first C++ implementation was different: The inclusion of template definitions was implicit, which created a certain illusion of separation (see Chapter 14 for details on this original model).
包含模型是一种很实用的方案，现在C++编译器实现中大多数也是采用这种方案。但是，最初的C++实现中情况有所不同：模板定义的包含是隐式的，这就给人以源文件和头文件是“分离”的错觉（有关这个原始模型的详细信息，请参阅第14章）。
The first C++ standard ([C++98]) provided explicit support for the separation model of template compilation via . The separation model allowed template declarations marked as export to be declared in headers, while their corresponding definitions were placed in CPP files, much like declarations and definitions for nontemplate code. Unlike the inclusion model, this model was a theoretical model not based on any existing implementation, and the implementation itself proved far more complicated than the C++ standardization committee had anticipated. It took more than five years to see its first implementation published (May 2002), and no other implementations appeared in the years since. To better align the C++ standard with existing practice, the C++ standardization committee removed exported templates from C++11. Readers interested in learning more about the details (and pitfalls) of the separation model are encouraged to read Sections 6.3 and 10.3 of the first edition of this book ([VandevoordeJosuttisTemplates1st]).
C++98(第1个C++标准) 通过导出模板(exported templates)支持了模板编译的分离模型。该分离模型允许被export标记的模板声明被放头文件里，相应的定义则放在CPP文件中。这一点与非模板代码的情况非常相似。不同于包含模型，这是一种不基于任何己有实现的理论模型，而且其实现本身也远比C++标准化委员会所预期的要来得复杂。直至5年之后(2002年5月)才看到其第一个实现的发布，此后的几年中也没有其他实现方式的出现。为了使C++标准与现有实践更好的保持一致，C++标准化委员会从C++11开始移除了导出模板(exported templates)。对分离模型更多细节(缺陷)有兴趣的读者可以去阅读一下本书第1版的6.3和10.3节相关的内容([VandevoordeJosuttisTemplates1st])。
It is sometimes tempting to imagine ways of extending the concept of precompiled headers so that more than one header could be loaded for a single compilation. This would in principle allow for a finer grained approach to precompilation. The obstacle here is mainly the preprocessor: Macros in one header file can entirely change the meaning of subsequent header files. However, once a file has been precompiled, macro processing is completed, and it is hardly practical to attempt to patch a precompiled header for the preprocessor effects induced by other headers. A new language feature known as modules (see Section 17.11 on page 366) is expected to be added to C++ in the not too distant future to address this issue (macro definitions cannot leak into module interfaces).
有时我们可能会期望可以扩展预编译头文件的concept，以便让每次编译可以加载多个头文件。原则上，这将允许用更细粒度的方法进行预编译。这里的主要障碍是预处理器：在一个头文件中，宏可以改变后面所#include的头文件的含义。但是，当一个文件经过预编译之后，宏处理也就完成了。这时，对于其他头文件经过预处理程序所获得的结果，要想在该结果中插入一个预编译头文件几乎是不现实的。有望在不久的将来，将一种被称为module的新语言特性(请参阅第366页的17.11节)添加到C++以解决此问题(宏定义不能泄漏到module接口中)
9.6 Summary
9.6 小结
• The inclusion model of templates is the most widely used model for organizing template code. Alternatives are discussed in Chapter 14.
模板的包含模型被广泛用来组织模板代码。在第14章将介绍另一种替代方法。
• Only full specializations of function templates need inline when defined in header files outside classes or structures.
当函数模板定义在类或结构体之外的头文件时，只有函数模板的完全特化版本才需要inline。
• To take advantage of precompiled headers, be sure to keep the same order for #include directives.
为了充分发挥预编译的特性，要确保#include指令的顺序相同。
• Debugging code with templates can be challenging.
Debug模板相关代码很有挑战性。