This is an unofficial snapshot of the ISO/IEC JTC1 SC22 WG21 Core Issues List revision 116a. See http://www.open-std.org/jtc1/sc22/wg21/ for the official list.

2024-12-19

230. Calls to pure virtual functions

According to 11.7.4 [class.abstract] paragraph 6,

Member functions can be called from a constructor (or destructor) of an abstract class; the effect of making a virtual call (11.7.3 [class.virtual]) to a pure virtual function directly or indirectly for the object being created (or destroyed) from such a constructor (or destructor) is undefined.

This prohibition is unnecessarily restrictive. It should not apply to cases in which the pure virtual function has been defined.

Currently the "pure" specifier for a virtual member function has two meanings that need not be related:

1. A pure virtual function need not be defined.
2. A pure virtual function must be overridden in any concrete derived class.

The prohibition of virtual calls to pure virtual functions arises from the first meaning and unnecessarily penalizes those who only need the second.

For example, consider a scenario such as the following. A class B is defined containing a (non-pure) virtual function f that provides some initialization and is thus called from the base class constructor. As time passes, a number of classes are derived from B and it is noticed that each needs to override f, so it is decided to make B::f pure to enforce this convention while still leaving the original definition of B::f to perform its needed initialization. However, the act of making B::f pure means that every reference to f that might occur during the execution of one of B's constructors must be tracked down and edited to be a qualified reference to B::f. This process is tedious and error-prone: needed edits might be overlooked, and calls that actually should be virtual when the containing function is called other than during construction/destruction might be incorrectly changed.

Suggested resolution: Allow virtual calls to pure virtual functions if the function has been defined.

Rationale (February, 2012):

In light of the nontrivial implementation issues such a change would raise, as well as the fact that this restriction has been accepted into the C++ design lexicon for many years, CWG decided not to make a change at this point. Further consideration, if any, should occur within EWG.

Rationale (February, 2014):

EWG determined that no action should be taken on this issue.