假设你有一套模拟股票处理的类层次结构，例如，购入流程，出售流程等。对这样的处理来说可以核查是非常重要的，所以随时会创建一个 transaction 对象，将这个创建记录在核查日志中是一个适当的要求。下面是一个看起来似乎合理的解决问题的方法：
class transaction { // base class for all
public: // transactions
transaction();
virtual void logtransaction() const = 0; // make type-dependent
// log entry
...
};
transaction::transaction() // implementation of
{
// base class ctor
...
logtransaction(); // as final action, log this
} // transaction
class buytransaction: public transaction {
// derived class
public:
virtual void logtransaction() const; // how to log trans-
// actions of this type
...
};
class selltransaction: public transaction {
// derived class
public:
virtual void logtransaction() const; // how to log trans-
// actions of this type
...
};
考虑执行这行代码时会发生什么：
buytransaction b;
很明显 buytransaction 的构造函数会被调用，但是首先，transaction 的构造函数必须先被调用，派生类对象中的基类部分先于派生类部分被构造。transaction 的构造函数的最后一行调用虚函数 logtransaction，但是结果会让你大吃一惊，被调用的 logtransaction 版本是在 transaction 中的那个，而不是 buytransaction 中的——即使被创建的对象类型是 buytransaction。基类构造期间，虚函数从来不会向下匹配（go down）到派生类。取而代之的是，那个对象的行为就好像它的类型是基类。非正式地讲，基类构造期间，虚函数禁止。 这个表面上看起来匪夷所思的行为存在一个很好的理由。因为基类的构造函数在派生类构造函数之前执行，当基类构造函数运行时，派生类数据成员还没有被初始化。如果基类构造期间调用的虚函数向下匹配（go down）到派生类，派生类的函数理所当然会涉及到本地数据成员，但是那些数据成员还没有被初始化。这就会为未定义行为和悔之晚矣的调试噩梦开了一张通行证。调用涉及到一个对象还没有被初始化的部分自然是危险的，所以 c++ 告诉你此路不通。
在实际上还有比这更多的更深层次的原理。在派生类对象的基类构造期间，对象的类型是那个基类的。不仅虚函数会解析到基类，而且语言中用到运行时类型信息（runtime type information）的配件（例如，dynamic_cast和 typeid），也会将对象视为基类类型。在我们的例子中，当 transaction 构造函数运行初始化 buytransaction 对象的基类部分时，对象的类型是 transaction。c++ 的每一个配件将以如下眼光来看待它，并对它产生这样的感觉：对象的 buytransaction 特有的部分还没有被初始化，所以安全的对待它们的方法就是视若无睹。在派生类构造函数运行之前，一个对象不会成为一个派生类对象。
同样的原因也适用于析构过程。一旦派生类析构函数运行，这个对象的派生类数据成员就被视为未定义的值，所以 c++ 就将它们视为不再存在。在进入基类析构函数时，对象就成为一个基类对象，c++ 的所有配件——虚函数，dynamic_casts 等——都如此看待它。
在上面的示例代码中，transaction 的构造函数直接调用了虚函数，对本 item 的规则的违例是显而易见的。这一违例是如此显见，以致一些编译器会给出警告。（其它的则不会）甚至除了这样的警告之外，这一问题几乎肯定会在运行之前暴露出来，因为 logtransaction 函数在 transaction 中是一个纯虚函数。除非它被定义（看似不可能，但确实可能），否则程序将无法连接：连接程序无法找到 transaction::logtransaction 的必需的实现。
在构造函数和析构函数中调用虚函数的问题并不总是如此容易被察觉。如果 transaction 有多个构造函数，每一个都必须完成一些相同的工作，好的软件工程为避免代码重复，会将共用的初始化代码，包括对 logtransaction 的调用，放入一个私有的非虚的初始化函数，叫做 init：
class transaction {
public:
transaction()
{ init(); } // call to non-virtual...
virtual void logtransaction() const = 0;
...
private:
void init()
{
...
logtransaction(); // ...that calls a virtual!
}
};
这个代码在概念上和早先那个版本相同，但是它更阴险，因为它很具代表性地会躲过编译器和连接程序的抱怨。在这种情况下，因为 logtransaction 在 transaction 中是纯虚函数，大多数运行时系统在纯虚函数被调用时，程序会异常中止（典型的结果就是给出一条信息）。然而，如果 logtransaction 是一个“常规的”虚函数（也就是说，非纯的虚函数），而且在 transaction 中有其实现，那个版本被调用，程序会继续一路小跑，让你想象不出为什么派生类对象创建的时候会调用 logtransaction 的错误版本。避免这个问题的唯一办法就是确保在你的构造函数和析构函数中，决不在你创建或销毁的对象上调用虚函数，构造函数和析构函数所调用的函数也要服从同样的约束。
但是，如何保证在任何时间 transaction 层次结构中的对象被创建时，都能调用 logtransaction 的正确版本呢？显然，在 transaction 的构造函数中在这个对象上调用虚函数的做法是错误的。
有不同的方法来解决这个问题。其中之一是将 transaction 中的 logtransaction 转变为一个非虚函数，这就需要派生类的构造函数将必要的日志信息传递给 transaction 的构造函数。那个函数就可以安全地调用非虚的 logtransaction。如下：
class transaction {
public:
explicit transaction(const std::string& loginfo);
void logtransaction(const std::string& loginfo) const; // now a non-
// virtual func
...
};
transaction::transaction(const std::string& loginfo)
{
...
logtransaction(loginfo); // now a non-
} // virtual call
class buytransaction: public transaction {
public:
buytransaction( parameters )
: transaction(createlogstring( parameters )) // pass log info
{ ... } // to base class
... // constructor
private:
static std::string createlogstring( parameters );
};
换句话说，因为在基类的构造过程中你不能使用虚函数，就改为由派生类传递必要的构造信息给基类的构造函数作为补偿。 在此例中，注意 buytransaction 中那个（私有的）static 函数 createlogstring 的使用。使用一个辅助函数创建一个值传递给基类的构造函数，通常比通过在成员初始化列表给基类它所需要的东西更加便利（也更加具有可读性）。将那个函数做成 static，就不会有偶然涉及到一个初生的 buytransaction 对象的仍未初始化的数据成员的危险。这很重要，因为实际上那些数据成员在一个未定义状态，这就是为什么在基类构造和析构期间虚函数不能首先匹配到派生类的原因。
things to remember
·在构造和析构期间不要调用虚函数，因为这样的调用不会匹配到当前执行的构造函数或析构函数所属的类的更深的派生层次。