Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!bloom-beacon!apple!arn@apple.com
From: arn@apple.com (Arn Schaeffer)
Newsgroups: comp.lang.c++
Subject: Virtual functions in constructors
Message-ID: <1129@internal.Apple.COM>
Date: 31 Mar 89 17:03:57 GMT
Sender: usenet@Apple.COM
Organization: Apple Computer, Inc.
Lines: 44

I am not sure if this message actually made it to the network outside of 
Apple Computer.  If it did, I'm sorry for the reposting.  Otherwise, here it is:

I have a question concerning what the proper semantics of virtual function 
calls appearing in a constructor (or destructor).  It does not appear that 
the "correct" behavior for this is documented.  There are atleast three 
possibilities concerning how these calls should be interpreted.  I have 
not been able to determine what the behavior is supposed to be.  I am 
interested in which option is the correct behavior and why.  


Option #1:
Do not allow virtual function calls in constructors.

Option #2:
Because base classes are initialized before derived classes, a virtual 
function appearing in the constructor of a base class should call the 
virtual function as it was defined for the base class.  This is the 
behavior that I see right now.  I suppose that the reasoning behind this 
is that since derived classes are uninitialized, a call to a virtual 
function (as defined in the derived class) could do a very bad thing like 
access fields defined in the derived class.  I also imagine that this is 
easier to implement since the vtable is fixed up along the way back down 
the class hierarchy to point to the correct virtual function definition as 
we construct the object.  This implementation seems to defy one of the 
invariants of the language concerning the invocation of virtual functions. 
Further, if you wanted to call the virtual function defined for the base 
class, you could do it with the scope resolution operator.

Option #3:
Virtual functions always invoke the definition in the derived class.  If 
you would like to call a specific function, use the scope resolution 
operator to achieve the behavior discussed in option
two.  It appears that this interpretation is convenient if the 
implementation of the base class can change based on the derived class.  
Certainly,  a somewhat degenerate use of parameterized types could present 
a partial solution to this problem; however, I'm wondering if there are 
other classes of problems that could benefit from this interpretation.

Thank-you for your help.

arn schaeffer (arn@apple.com)

The opinions expressed are not necessarily those of Apple Computer.