🚀 go-pugleaf

In article <9511021143.AA01851@slsv7xt.lts.sel.alcatel.de>, kanze
<kanze@lts.sel.alcatel.de> wrote:

>In article <1995Oct31.171443.3987@oma.com> rmartin@oma.com (Robert
>Martin) writes:

>|> harald@bion.kth.se (Harald Winroth) writes:

>|> >There is a common pattern in which a base class implements an algorithm but
>
>|> >leaves some of the steps unspecified (in C++ typically as pure virtual
>|> >functions). These steps are later defined in subclasses. The current 
>|> >standard draft prevents this pattern to be used in constructors, which I
>|> >think is unfortunate.
>
>|> I agree that the current rules for deploying virtual functions in
>|> constructors and destructors can be inconvenient at times.  But they
>|> have a distinct advantage.  The rules, written as they are, guarantee
>|> that no member function of a class (other than one of its
>|> constructors) will be called until all the members and bases of that
>|> class have been initialized.

>Actually, the rules make this guarantee even for constructors and
>destructors.  The only code in class X that can be executed before all
>of the subobjects are initialized is the initialization lists of
>constructors; off hand, I don't believe that (non-static) member
>functions can be called in initialization lists.  (I'm too lazy to
>check, and since it isn't something I'd want to do anyway.)
>
>IMHO, this is a *very* important guarantee, well worth the occasional
>inconvenience. 
>
>|> If the rules allowed virtual deployment in constructors or
>|> destructors, then functions could be called in classes where the
>|> members and/or bases had not been initialized, or had been destructed.
>|> And this, IMHO, would be untennable.
>
>Also, these functions would presumably not have anyway of knowing that
>the subobjects were only raw memory.  So they would probably use
>functions of the subobjects, with the result that everyday member
>functions end up getting called on raw memory.  Not exactly what I
>would call a healthy state of affairs.
>--
>
>James Kanze         Tel.: (+33) 88 14 49 00        email: kanze@gabi-soft.fr
>GABI Software, Sarl., 8 rue des Francs-Bourgeois, F-67000 Strasbourg, France
>Conseils en informatique industrielle --
>                              -- Beratung in industrieller Datenverarbeitung



Hmmm! The question doesn't seem to be why virtual functions calls are not
allowed in ctor/dtors, but why there isn't any kind of sepcial virtual
functions which *could* be allowed to be called in such a context.

Standard, "ordinary" virtual function would behave as usual, but a special
form of them, introcudced with an apropriate keyword would tell the
compiler
"Hey, I know what I'm doing, and I take personal responsability for not
using any field not defined in the first base-class which declared me".

What about using a "constructor" keyword, meaning both "virtual" and "can
be called by ctors/dtors in any derived class" ?
Jean-François Brouillet
Macintosh Software Developer
verec@micronet.fr      (preferred)
verecundus@eworld.com


---
[ 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. ]