🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Article View: comp.std.c++
Article #2340

Re: Why allow virtual function calls in constr

#2340
From: Fergus Henderson
Date: Sun, 29 Oct 1995 14:58
52 lines
3134 bytes
clamage@Eng.Sun.COM (Steve Clamage) writes:

>Other language designs are possible. For example, we could say that when
>you construct a derived, the object is a derived even before the derived
>constructor begins to run, and you get the derived virtual functions when
>called from the base constructor or destructor. Sometimes that will be the
>effect you want.

Yes.  In fact I think that would *often* be the effect you want.

(Incidentally, it would probably result in slightly more efficient code than
the current rule, since implementations would only need to assign
the vtable pointer once, whereas with the current rule in the general case
they have to assign to it many times -- once for each base class.)

>But in the general case, member functions of derived
>could be called which depend on the derived constructor having already
>run, and on the derived destructor not yet having run.  This will not always
>be the case. We would need additional rules, such as
>1. You cannot call a virtual function from a ctor/dtor, or
>2. You have to write a virtual function so that it doesn't matter whether
>   the ctor or dtor for its type has run or not, or
>3. If you call a virtual function from a ctor/dtor, the results are undefined.


You are overstating the case here.  Option 2 is far more sweeping than
it needs to be.  An alternative is a more restricted version of option 2
that only applies to those virtual functions which are called from
base class ctor/dtors:

2b. If a virtual function is called from a base class ctor or dtor, then
    you have to write it so that it doesn't matter whether the ctor or dtor
    for its class has run or not.

>With this object model, you cannot define the semantics of a virtual
>function call from a ctor/dtor unless you somehow enforce option 2 above.

No, you only have to enforce option 2b, which is a lot easier.

If this enforcement was found to be difficult, then perhaps
such virtual functions could be identified with a particular
keyword (`raw'?), so that the compiler could then enforce it:
only functions declared `raw' could be called from a constructor or
destructor.

--
Fergus Henderson             	WWW: http://www.cs.mu.oz.au/~fjh
fjh@cs.mu.oz.au              	PGP: finger fjh@128.250.37.3
---
[ comp.std.c++ is moderated.  Submission address: std-c++@ncar.ucar.edu.
  Contact address: std-c++-request@ncar.ucar.edu.  The moderation policy
  is summarized in http://dogbert.lbl.gov/~matt/std-c++/policy.html. ]
Technical Details
Message-ID: <9530301.15557@mulga.cs.mu.OZ.AU>
Path: arc1-ca.pugleaf.net!in1.uu.net!bounce-back
References: <46kuqc$j45@manuel.anu.edu.au> <46mgqo$e5b@engnews2.Eng.Sun.COM>

Show Full Headers
Complete Article Headers
Approved: fjh@cs.mu.oz.au
Date: 29 Oct 95 14:58:49 GMT
From: fjh@munta.cs.mu.OZ.AU (Fergus Henderson)
Message-ID: <9530301.15557@mulga.cs.mu.OZ.AU>
Newsgroups: comp.std.c++
Organization: Computer Science, University of Melbourne, Australia
Path: arc1-ca.pugleaf.net!in1.uu.net!bounce-back
References: <46kuqc$j45@manuel.anu.edu.au> <46mgqo$e5b@engnews2.Eng.Sun.COM>
Return-Path: <daemon@migs.UCAR.EDU>
Subject: Re: Why allow virtual function calls in constr
X-Auth: PGPMoose V1.1 PGP comp.std.c++
 iQBFAgUBMJOXReEDnX0m9pzZAQHX5wGAgmgtZJn7e5TTjFVk1/lPh0gp4hC0hEDO
 31hJuzg43C2+ntOk7c/1racjffAsanWD
 =qJXp