我记得在一本c++书中(很久以前)读到，使用内联构造函数和析构函数并不是一个好主意，特别是对于派生类。我知道内联会导致对象代码的膨胀，但是有没有其他的设计考虑会阻止内联构造函数和析构函数呢?当然，大多数编译器可能会拒绝内联并继续创建函数体，但如果他们要内联，可能会付出什么代价呢?
编译器可以自由地内联未声明为内联的代码，也可以自由地不内联已声明为内联的代码。我见过编译器做这两件事。正因为如此，内联关键字并不像大多数人认为的那样。它的意思是允许一个定义规则的异常，所以你可以把函数等放在头文件中，而不会得到链接器错误。
所以建议是垃圾，让编译器决定什么是最好的内联，什么不是。
绝对没有任何理由避免使用内联构造函数和析构函数。这本书错得离谱。
我不了解构造函数，但析构函数通常是virtual。在大多数情况下，编译器内联虚函数是没有意义的，因为直到运行时才知道哪个覆盖将被调用。
除了@oli在他的回答中提到的原因:
这本书可能会指导不要内联构造函数和析构函数，因为即使是看似微不足道或空的函数也可能经常包含大量由编译器隐式生成的代码，而实际的函数定义最终可能会相当大，这可能会导致代码膨胀。
话虽如此，让编译器实际决定是否内联函数调用(甚至是构造函数和析构函数)是谨慎的，大多数现代编译器都会通过内联适当地优化函数。
我很确定这不是关于c++如何处理代码的，因为，如前所述，这只是一个提示。
如果你开始考虑软件工程，事情就会改变。所有内联函数的更改将强制重新编译所有依赖文件。
当您维护一个库并想要发送一个bug修复版本，以保持ABI兼容时，情况会变得更糟。内联函数不能被其他版本替换，因为调用代码可能不会被重新编译。因此，当您的非内联函数可以随意替换时，当需要更改内联函数时，您必须移动到接口的新版本。
结合构造函数很少被编译器内联这一事实，你就可以想象为什么一本书会给出上面提到的建议了。