TITLE: explicit constructor call of a virtual base class, a rationale

EVERS: Wil Evers <bouncer@dev.null>

> >If that's the committee's official position, then the use of
> >virtual base classes lacking a default constructor should be
> >deprecated in the next version of the standard.

GLASSBOROW: Francis Glassborow <francisG@robinton.demon.co.uk>

> The Committees AFAIK do not have an official position, however they
> are unlikely to spend time discussing an issue like this one unless
> someone present takes the trouble to present a paper on the subject
> and can provide all relevant wording to deal with this special case
> and demonstrate that it is free of affects to anything else. It is a
> matter of priorities and committee time is a precious resource.

KANZE: James.Kanze@dresdner-bank.com

For what it's worth, Paul Lucas, John Skaller and myself considered
the problem in detail some years back.  We actually started to develop
a proposal to eliminate the problem, but in the end, we dropped it
because it became clear to us that virtual base classes without a
default constructor were simply bad practice anyway.

The reason behind the rule is simple: if the most derived class
doesn't initialize the virtual base, who should.  Consider the
following hierarchy:

        VB
       /  \
      L    R
       \  /
        D1
        |
        D2

Ignoring the virtual base, the order of initialization would be L, R,
D1 and D2.  Now, it is clear that VB must be initialized before L.
Suppose thus that L initializes it.  How can L possibly know the
correct arguments for it to serve equally well as a base to R.  At the
earliest, it can be initialized by D1, who "knows" that it serves as
base for both L and R, and can choose an appropriate argument.

It would thus seem that the correct solution is for it to be
initialized by D1.  However, consider the following:

        VB   VB2
       /  \ / |
      L    R  |
       \  /   |
        D1    |
        |     |
        D2    |
         \   /
          \ /
           D3

Of course, the correct solution in this case would be for VB to be
initialized by D1, but VB2 to be initailized by D3.

Now consider that all of the classes are separately compiled.  And
that later in the game, someone adds a D4 which derives from D3, and
virtually from VB.  Suddenly, VB must be initialized from D4, and
*not* from D1.

How do you implement this?  In the usual implementation, the compiler
generates a hidden boolean argument, which is set true for the calls
of the base class constructors from the derived class constructor, and
false everywhere else.  This is relatively simple.  The alternative,
if one accepts that the initialization must be at least high enough in
the hierarchy so that all users are known, is to pass one flag per
virtual base.  Doable of course, but is it worth it?

And of course, the reason why it is generally considered bad practice
to require a parameter of a virtual base: suppose that VB has an int
parameter.  What happens if L needs it to be 0, and R to be 1?

TRIBBLE: David Tribble (david@tribble.com)

It's because of examples like this that I *always* declare/define the
  1. destructor
  2. default constructor
  3. copy constructor
  4. operator =
in every class I write (especially if they should be private).

What little, if any, overhead they introduce at execution time is more
than compensated for by the potential headaches and worry that I lose
in the bargain.





_______________________________________________
cpptips mailing list
http://cpptips.hyperformix.com