> What do you think of the way in which C++ treats virtual
> calls in constructors and destructors? Java, by contrast,
> doesn't do anything special with virtual calls during
> construction. Although it seems C++ would be safer because
> of this special treatment, Scott Meyers suggests you avoid
> virtual calls anyway. What's your opinion?

I don't know what Java does, but I think C# does something similar, i.e. calls to a virtual in a constructor call the most derived version.

IMO C++ does the right thing here, C# (and Java?) don't. The danger is in the data members, as Scott highlights.

Taking Scott's example and trivialising it :-)

namespace VirtualConstruction
{
	public abstract class Base
	{
		public Base() 
		{
		}
		public abstract void Log();
	}
 
	public class Derived : Base
	{
		public Derived()
		{
			buf = new StringBuilder();
			Log();
		}
		public override void Log()
		{
			buf.Append( "Derived" );
			Console.WriteLine( buf.ToString() );
		}
		private StringBuilder buf;
	}
 
	public class MoreDerived : Derived
	{
		public MoreDerived()
		{
			buf = new StringBuilder();
			Log();
		}
		public override void Log()
		{
			buf.Append( "MoreDerived" );
			Console.WriteLine( buf.ToString() );
		}
		private StringBuilder buf;
	}
 
	class VirtualTester
	{
		static void Main(string[] args)
		{
			Base d = new Derived();
			Base md = new MoreDerived();
		}
	}
}

This is C#, and it crashes when MoreDerived is created. Note that in all cases, the StringBuilder object is created before Log() is called. Except it isn't because the base class CTR gets called before that, and in turn tries to call the more derived virtual function.

Can anyone indicate what Java does with the equivalent code?

Steve

In Java, virtual methods do just work in their normal way in constructors (as Mr Meyers implied). But any member variables used wouldn't be fully initialized.

Object construction in Java has an extra stage, compared to C++: member variable storage is zeroed before any constructors are executed. So those zero values are what a virtual method would encounter, since its corresponding constructor won't have been called yet.

You could say Java has default construction.

A Java version of Mr Love's code would throw a null-object-reference exception when attempting to do the buf.Append in MoreDerived::Log.

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.

I usually phrase this as Virtual functions aren't virtual during construction and destruction which is much easier to understand and memorize.

The C++ language design decision to make virtual functions non-virtual when called from ctors/dtors is a mistake that simply leads to incorrect program behavior that is difficult to debug. It would be better for C++ to prohibit calls to virtual functions from ctors/dtors and enforce this behavior with a runtime error. The programmer can easily find the source of the error and correct it by creating a non-virtual function that is called from both the virtual function and the ctor/dtor, if the intent is to achieve the existing behavior. I think that the current C++ design was simply easier to implement; my proposal would probably require initializing the vtable to zeros before construction and not adding any function addresses until after all ctors have been called.

All of these languages implement the virtual functions from the constructor issue in the correct way given the context of the language. It all depends on how each language initialises its data members.

For C# and Java, an object's data members are always initialised - either explicitly by the user or implicitly (to zero) by the runtime. Therefore, calling virtual methods will always have predictable results even if they're not exactly what the programmer expects in some cases.

On the other hand, the data members in a C++ object are *not necessarily* initialised until *all* of the constructors in the class hierarchy have returned. Calling virtual methods that access data members from derived classes will therefore have unpredictable results and that is why it is not supported in C++.

Calling virtual functions from constructors works for me.
(Accessing data is a separate issue!)

// Re: http://www.artima.com/cppsource/nevercall.html
// "Never call virtual functions during construction / destruction"
//

#include <iostream>

using std::cout;
using std::endl;

class Base1
{
public:
Base1(){ cout << "Constructor: Base1 calling virtual Base1::vf1()..." <<endl; vf1(); }
virtual ~Base1(){ cout << "Destructor : Base1" << endl;}
virtual void vf1 () { cout << "virtual Base1::vf1 called!" << endl; }
virtual void vf2 () = 0;
};
class Derived1 : public Base1
{
public:
Derived1() { cout << "Constructor: Derived1 calling virtual Derived1::vf1()..." <<endl; vf1();
cout << "Constructor: Derived1 calling virtual Derived1::vf2()..." <<endl; vf2(); }
~Derived1(){ cout << "Destructor : Derived1" << endl;}
virtual void vf1 () {cout << "virtual Derived1::vf1 called!" << endl;}
virtual void vf2 () {cout << "virtual Derived1::vf2 called!" << endl;}
};

void main ()
{
bool use_base_class_ptr = false;

if (use_base_class_ptr)
{
Base1 *pb1 = new Derived1;
delete pb1;
/** Produces the following output: **/
// Constructor: Base1 calling virtual Base1::vf2()...
// virtual Base1::vf2 called!
// Constructor: Derived1 calling virtual Derived1::vf1()...
// virtual Derived1::vf1 called!
// Constructor: Derived1 calling virtual Derived1::vf2()...
// virtual Derived1::vf2 called!
// Destructor : Derived1
// Destructor : Base1
// Press any key to continue
}
else if (!use_base_class_ptr)
{
Derived1 d1;
/** Produces the following output: **/
// Constructor: Base1 calling virtual Base1::vf1()...
// virtual Base1::vf1 called!
// Constructor: Derived1 calling virtual Derived1::vf1()...
// virtual Derived1::vf1 called!
// Constructor: Derived1 calling virtual Derived1::vf2()...
// virtual Derived1::vf2 called!
// Destructor : Derived1
// Destructor : Base1
// Press any key to continue
}
}

If you want to call virtual functions in a constructor in C++, it might be useful to explicitly scope the function call with the class name. e.g.:

class A
{
  public:
    A()
    {
        A::func();
    }
    virtual void func() { }
};

Even though the code will run the same with or without the scope, this will help future readers of the code to see that A's version of func will always be called, regardless of the type of end-object being constructed.

I have some problems with the Scott Meyers's example. The example (if my interpretation below is correct) does not compile at all!!! In MS VS 2005 I have the following link error:
error LNK2001: unresolved external symbol "public: virtual void __thiscall Transaction::logTransaction(void)const " (?logTransaction@Transaction@@UBEXXZ)

If I didn't make any mistake it turns aout that somebody forgot the first lesson is teaching: Test your code!

And why he didn't call the log from the derive class constructor in order to have the expected result?

class Transaction {
public:
Transaction();
virtual ~Transaction(void);
virtual void logTransaction() const = 0;
};

Transaction::Transaction()
{
logTransaction();
}

Transaction::~Transaction()
{
}

class BuyTransaction: public Transaction {
public:
virtual void logTransaction() const;
};

void BuyTransaction::logTransaction() const
{
printf("BuyTransaction::logTransaction");
}


class SellTransaction: public Transaction {
public:
virtual void logTransaction() const;
};

void SellTransaction::logTransaction() const
{
printf("SellTransaction::logTransaction");
}