这些代码并不代表真正的编译器所生成的，因为真正的编译器会用更复杂的方法处理异常。尽管如此，他还是准确地反映了 Derived 的“空”构造函数必须提供的行为。不论一个编译器的异常多么复杂，Derived 的构造函数至少必须调用他的数据成员和基类的构造函数，而这些调用（他们自己也可能是 inline 的）会影响他对于 inline 化的吸引力。
同样的原因也适用于 Base 的构造函数，所以假如他是 inline 的，插入他的全部代码也要插入 Derived 的构造函数（通过 Derived 的构造函数对 Base 的构造函数的调用）。而且假如 string 的构造函数碰巧也是 inline 的，Derived 的构造函数中将增加五个那个函数代码的拷贝，分别对应于 Derived 对象中的五个 strings（两个继承的加上三个他自己声明的）。也许在现在，为什么说是否 inline 化 Derived 的构造函数不是个不经大脑的决定就很清楚了。类似的考虑也适用于 Derived 的析构函数，用同样的或不同的方法，必须确保任何被 Derived 的构造函数初始化的对象被完全销毁。
库设计者必须评估声明函数为 inline 的影响，因为为库中的客户可见的 inline 函数提供二进制升级版本是不可能的。换句话说，假如 f 是个库中的一个 inline 函数，库的客户将函数 f 的本体编译到他们的应用程式中。假如一个库的实现者后来决定修改 f，任何使用了 f 的客户都必须重新编译。这常常会令人厌烦。在另一方面，假如 f 是个非 inline 函数，对 f 的改变只需要客户重新连接。这和重新编译相比显然减轻了很大的负担，而且，假如库中包含的函数是动态链接的，这就是一种对于用户来说完全透明的方法。
为了程式研发的目标，在头脑中牢记这些需要考虑的事项是很重要的，但是从编码期间的实用观点来看，占有支配地位的事实是：大多数调试器会和 inline 函数发生冲突。这不应该是什么重大的发现。您怎么能在一个不在那里的函数中配置断点呢？虽然一些构建环境设法支持 inline 函数的调试，多数环境还是简单地为调试构建取消了 inline 化。
这就导出了一个用于决定哪些函数应该被声明为 inline，哪些不应该的合乎逻辑的策略。最初，不要 inline 任何东西，或至少要将您的 inline 化的范围限制在那些必须 inline 的和那些实在微不足道的函数上。通过慎重地使用 inline，您能够使调试器的使用变得容易，但是您也将 inline 化放在了他本来应该在的地位：作为一种手动的优化。不要忘记由经验确定的 80-20 规则，他宣称一个典型的程式用 80% 的时间执行 20% 的代码。这是个重要的规则，因为他提醒您作为一个软件研发者的目标是识别出能全面提升您的程式性能的 20% 的代码。您能够 inline 或用其他方式无限期地调节您的函数，但除非您将精力集中在正确的函数上，否则就是白白浪费精力。
Things to Remember
·将大部分 inline 限制在小的，调用频繁的函数上。这使得程式调试和二进制升级更加容易，最小化潜在的代码膨胀，并最大化提高程式速度的几率。
·不要仅仅因为函数模板出现在头文档中，就将他声明为 inline。
(e129)
