似乎在静态编译的 C++ 和 D 语言中,模板元编程是一种流行的技术,对模板实例化膨胀有相当多的关注。在我看来,这主要是一个理论上的问题,除了资源非常有限的嵌入式系统。在嵌入式空间之外,我还没有听说过有人能够证明它在实践中是一个问题的例子。
任何人都可以在资源严重受限的嵌入式系统之外提供一个示例,说明模板实例化膨胀在实践中很重要并且具有可测量的、实际上显着的负面影响?
C++ 中几乎没有问题,因为您可以在 C++ 中执行的模板数量受到其复杂性的限制。
然而,在 D 中……在 CTFE(编译时函数评估)存在之前,我们不得不使用模板进行字符串处理。这也是在 DMD 中压缩大的重整符号的原因 - 用作模板参数的字符串成为重整符号名称的一部分,并且当使用较长的代码段(例如)实例化模板时,生成的符号大小会惊人地爆炸对象格式.
现在好多了。但总的来说,模板仍然会导致很多臃肿,原因很简单——它们解析速度更快,比 C++ 更强大,所以人们自然会更多地使用它们(即使在技术上不需要模板的情况下)。我必须承认我是这里的主要违规者之一(如果您愿意,可以查看tools.base,但请务必随身携带一个 barf 包——该文件实际上是 90% 的模板代码)。
模板膨胀不是问题(这是心理问题而不是代码问题)。
是的,它可以变大。但是有什么选择呢?
您可以自己手动编写所有代码(每种类型一次)。您是否认为手动编写会使其更小。编译器仅实例化它实际需要的版本,链接器将删除分布在编译单元中的多个副本。
所以没有实际的膨胀。
它只是在构建你使用的东西。如果您使用许多不同的类型,则需要编写更多代码。
我认为您需要找到一个较旧的编译器才能在实践中看到模板代码膨胀。现代 C++ 编译器(和链接器)已经能够优化它一段时间了。
我认为主要是心理膨胀。下一个处理你的代码的程序员首先需要弄清楚它的哪个子集很重要。
模板实例膨胀在实践中是一个问题,因为它会增加(很多!!!)编译和链接时间。
我个人认为 c++ #1 问题是编译时间,主要是由于模板。
我参与了一个有大约 50 个库的项目。我们有自己的使用模板的 rtti 系统。由于模板膨胀,我不得不重写
以下是一些数字: