> For the complete documentation index, see [llms.txt](https://sahibyar.gitbook.io/effective-cpp-summary/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://sahibyar.gitbook.io/effective-cpp-summary/chapter-2-constructors-destructors-and-assignment-operators/item-9.md).

# Item 9 - Never call virtual functions during construction or destruction.

Suppose you've got a class hierarchy for modelling stock transactions, e.g., buy order, sell orders, etc. It's important that such transaction be auditable, so each time a transaction object is created, an appropriate entry needs to be created in an audit log. This seems like a reasonable way to approach the problem:

```
class Transaction {                             // base class for all transactions.
public:
    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 transactions of this type
    ...
};

class SellTransaction: public Transaction    // derived class
{
public:
    virtual void logTransaction() const;    // how to log transactions of this type
    ...
}
```

Consider what happens when this code is executed:

```
BuyTransaction b;
```

Clearly a `BuyTransaction` constructor will be called, but first, a `Transaction` constructor must be called; base class parts of derived class objects are constructed before derived class parts are. The last line of the `Transaction` constructor calls the virtual function `logTransaction`, but there is where the surprise comes in. The version of `logTransaction` that's called is the one in `Transaction`, not the one in `BuyTransaction` — even though the type of object being created is `BuyTransaction`. During base class construction, virtual functions never go down into derived classes.

In our example, while the `Transaction` constructor is running to initialize the base class part of a `BuyTransaction` object, the object is of type `Transaction`. That's how every part of C++ will treat it, and the treatment makes sense: the `BuyTransaction` specific parts of the object haven't been initialized yet, so it's safest to treat them as if they didn't exist.

> An object doesn't become a derived class object until execution of a derived class constructor begins.

They same reasoning applies during destruction. Once a derived class destructor has run, the object's derived class data members assume undefined values, so C++ treats them as if they no longer exist. Upon entry to the base class destructor, the object becomes a base class object, and all parts of C++ — virtual functions, `dynamic_cast`, etc., — treat it that way.

It's not always so easy to detect calls to virtual functions during construction or destruction. if `Transaction` had multiple constructors, each of which had to perform some of the same work, it would be good software engineering to avoid code replication by putting the common initialization code, including the call to `logTransaction`, into a private non-virtual initialization function, say, `init`:

```
class Transaction {
public:
    Transaction()
    { init(); }                                // call to non-virtual
    virtual void logTransaction() const = 0;
    ...
private:
    void init()
    {
         ...
         logTransaction();                    // that calls a virtual!
     }
 };
```

This code is conceptually the same as the earlier version, but it's more insidious, because it will typically compile and link without complaint. In this case, because `logTransaction` is pure virtual in `Transacction`, most runtime systems will abort the program when the pure virtual is called. However, if `logTransaction` were a normal virtual function (i.e. not pure virtual) with an implementation in `Transaction`, that version would be called, and the program would merrily trot along, leaving you to figure out why the wrong version of `logTransaction` was called when a derived class object was created.

## Reasonable Solution:

There are different ways to approach this problem. One is to turn `logTransaction` into a non-virtual function in `Transaction`, then require that derived class constructors pass the necessary log information to the `Transaction` constructor. That function can then safely call the non-virtual `logTransaction`. Like this:

```
class Transaction {
public:
    explicit Transaction( const std::string& logInfo);
    void logTransaction( const std::string& logInfo) const;    // now a non-virtual function
    ...
};
Transaction::Transaction( const std::string& logInfo)
{
    ...
    logTransaction(logInfo)                                    // now a non-virtual call
}
class BuyTransaction: public Transaction {
public:
    BuyTransaction(parameters): 
        Transaction( createLogString(parameters))             // passing log info to base class constructor
    { ... }
    ...
private:
    static std::string createLogString(parameters);
};
```

In other words, since you can't use virtual functions to call down from base classes during construction, you can compensate by having derived classes pass necessary construction information up to base class constructors instead.

In this example, note the use of the ***private static*** function **`createLogString`** in `BuyTransaction`. Using the helper function to create a value to pass to a base class constructor is often more convenient than going through contortions in the member initialization list ot give the base class what it needs.

**Things to Remember:**

* Don't call virtual functions during construction or destruction, because such calls will never go to a more derived class than that of the currently executing constructor or destructor.