似乎在C ++和D中，静态编译的语言和模板元编程是一种流行的技术，对模板实例化膨胀有很多关注。除了资源非常有限的嵌入式系统外，在我看来，这似乎主要是理论上的问题。在嵌入式空间之外，我还没有听说过某个人能够在实践中证明这是一个问题的例子。
任何人都可以在资源有限的嵌入式系统之外提供一个示例，其中模板实例化膨胀在实践中 并具有可测量的，实际上重要的负面影响？
答案 0 :(得分：10)
C ++中没有什么问题，因为你可以在C ++中做的模板内容的数量受其复杂性的限制。
但是在D中......在CTFE（编译时功能评估）存在之前，我们必须使用模板进行字符串处理。这也是在DMD中压缩大错位符号的原因 - 用作模板参数的字符串成为错位符号名称的一部分，并且当实例化具有较长代码段的模板时（例如），得到的符号大小将极大地爆炸对象格式
现在好多了。但总的来说，模板仍然会导致很多膨胀，原因很简单 - 它们解析速度更快，而且比C ++更强大，所以人们自然会使用它们更多（即使在技术上不需要的情况下） / em>模板）。我必须承认我是这里的主要罪犯之一（如果你愿意的话，可以看看tools.base，但一定要把手提袋放在手边 - 这个文件实际上是90％的模板代码。）
答案 1 :(得分：7)
模板膨胀 NOT 是一个问题（这是一个心理问题，而不是代码问题）。
是的它可以变大。但是替代方案是什么呢？ 您可以手动编写所有代码（每种类型一次）。你认为手动编写它会使它变小。编译器只会实例化它实际需要的版本，链接器将删除分布在编译单元上的多个副本。
所以没有实际的膨胀 它只是在构建你使用的东西。如果您使用许多不同类型，则需要编写更多代码。
答案 2 :(得分：3)
我认为您需要找到一个较旧的编译器才能在实践中看到模板代码膨胀。现代C ++编译器（和链接器）已经能够将它优化一段时间了。
答案 3 :(得分：2)
我认为这主要是心理膨胀。下一个编写代码的程序员首先需要弄清楚它的哪个子集很重要。
答案 4 :(得分：1)
模板实例膨胀在实践中是一个问题，因为它可以增加（很多!!!）编译和链接时间。
我个人认为c ++＃1问题是编译时间，主要是由于模板。
我参与了一个包含大约50个库的项目。我们有自己的rtti系统使用模板。由于模板膨胀，我不得不重写
以下是一些数字：