为什么内联构造函数和析构函数在C ++中不是一个好主意？

Question

我记得在其中一本C ++书籍（很久以前）中读到，内联构造函数和析构函数尤其适用于派生类并不是一个好主意。 我理解内联会导致一些膨胀的目标代码，但有没有其他设计考虑因素阻碍内联构造函数和析构函数？当然，大多数编译器可能会拒绝内联并继续创建一个函数体，但如果他们要内联可能需要付出的代价呢？

Answer 1

编译器可以自由内联未内联声明的内联代码，并且不必内联您声明的内联代码。我见过编译器会做这两件事。因此，内联关键字并不意味着大多数人认为它的作用。它的意思是允许对一个定义规则进行例外处理，因此您可以将函数等放在头文件中，而不会出现链接器错误。

所以建议是垃圾，让编译器决定什么是最好的内联和什么不是。将内联放在需要它的地方以防止链接器错误，就是这样。

Answer 2

绝对没有理由避免使用内联构造函数和析构函数。这本书错了，因为错误可以。

Answer 3

除了@oli在回答中提到的原因外：

本书可能指导不内联构造函数和析构函数，因为即使看似琐碎或空函数也可能经常包含许多由编译器隐式生成的代码，实际的函数定义可能最终会变得非常大，这可能会导致代码膨胀。

尽管如此，谨慎的做法是让编译器实际决定是否内联函数调用（甚至是构造函数和析构函数），大多数现代编译器都会通过内联来适当地优化函数。

Answer 4

我不了解构造函数，但析构函数通常是virtual。在大多数情况下，编译器内联虚函数是没有意义的，因为直到运行时才会知道要调用哪个覆盖。

Answer 5

我很确定这与C ++对代码的作用无关，因为如上所述，它只是一个提示。

如果你开始考虑软件工程，那么事情会发生变化。所有内联函数更改都将强制重新编译所有相关文件。

当你维护一个库并希望发送一个bug修复版本，保持ABI兼容时会变得更糟。内联函数不能被其他版本替换，因为调用代码可能无法重新编译。因此，可以随意替换非内联函数的位置，当内联函数需要更改时，必须转移到新版本的接口。

将这与构造函数很少被编译器实际内联的事实相结合，然后你可以想象为什么一本书会提供所提到的建议。