基类与模板对比生成的代码与宏

Question

我必须制定出一些小型框架，这些框架将被我们的一些应用程序使用。除此之外，该框架将在同一个应用程序中多次使用，但配置略有不同。配置的“本质”比仅具有一些配置选项和一些设置器更复杂。在实践中，应用程序必须提供自己的数据结构，这些数据结构将被合并到框架中，使其更加复杂。

我在编写框架时可以看到以下4种选择：

• 将公共逻辑放在基类中，并告诉应用程序它应该从此基类继承
• 将逻辑放在模板化的类中，应用程序应该在其中传递自己的类实现
• 在配置文件中描述应用程序的特定配置，并在构建过程中生成C ++代码
• 提供可用于将“配置”扩展为实际代码的宏

在选择一个好的替代方案时应该考虑哪些论点？

这些替代方案中的一些是否比其他方案更好，为什么？

请注意，就我而言，性能是最重要的。

Answer 1

如果峰值性能确实是一个问题，我会避免运行时多态性，这不仅是因为虚拟函数调用的vtable查找，而是因为：

• 内联虚拟调用以允许有效的跨函数边界优化是很难做到的（同样适用于编译到运行时加载的共享库（“插件”）的生成代码和使用编译器从生成的代码编译的静态链接模块这不支持链接时优化。）
• 多态对象通常必须进行堆分配以避免切片，可能会产生额外的运行时开销

宏往往难以调试，所以除非你需要能够进行字符串连接，这在某些情况下是模板的独特优势，我个人会使用静态多态技术来寻找基于模板的解决方案，就像你一样表示，curiously recurring template pattern和/或（如果适用）模板专业化处理自定义数据结构。

Answer 2

使用特定于平台的头文件。这是一个额外的选择，类似于宏，但没有瑕疵。

如果必须使用宏，请仅在包含特定于平台的标头的config标头内执行此操作。但通常只需定义特定于平台的结构并将其用作子对象就足够了。

Answer 3

你的表现是什么意思？如果它是最终代码运行的性能，请记住，涉及虚函数的类继承的解决方案在调用时会产生很小的开销。

其他解决方案会导致项目构建阶段产生额外开销，并且由于代码“重复”（通过模板混合，自定义代码生成或宏扩展）而导致可执行文件稍大一些。