🚀 go-pugleaf

In article j45@manuel.anu.edu.au, keagchon@mehta.anu.edu.au (Geoff Keating 9205156) writes:
>
>The draft WP says that [section class.cdtor:3]
>
>  When  a  virtual function is called directly or indirectly from a con-
>  structor (including from its ctor-initializer) or from  a  destructor,
>  and the object to which the call applies is the object under construc-
>  tion or destruction, the function called is the  one  defined  in  the
>  constructor  or destructor's own class or in one of its bases, but not
>  a function overriding it in a class derived from  the  constructor  or
>  destructor's  class, or overriding it in one of the other base classes
>  of the complete object (_intro.object_).
>
>Why allow this, rather than refusing calls to virtual functions at
>all? It would be nice to say that `if I override this function, then
>the old version will _never_ be called on objects of this type'.

This language design decision is explained in the ARM, among other places.
Given
	class base { ... };
	class derived : public base { ... };
suppose we constuct an object of type derived.

The first thing that happens is that the base constructor runs. While that
constructor is running, the object has type base, not type derived. Hence,
any virtual functions that are called will never be those declared in
derived, because the object at this moment is not a derived object; it is
a base object. That is (part of) the C++ object model.

In other words, when a constructor runs, the object has exactly the type
of the constructor's class.

The same is true of destructors. When the body of the derived destructor
completes, the destructor for base runs. At that point, the object has
ceased being a derived (the derived part has been destroyed), and is now
a base object.

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

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.
Example:

	class base {
	public:
		virtual int f() { return 0; }
		...
	};

	class derived : public base {
	public:
		virtual int f();
		derived(const char* name) { str = new ifstream(name); }
		~derived() { delete str; }
	private:
		ifstream* str;
	};

	int derived::f() {
		int i;
		*str >> i; // fails before ctor runs and after dtor runs
		return i;
	}

If a constructor or destructor for base calls f() and gets derived::f(),
you cannot define any semantics for the result. Hence my three options above.
This seems to me to be inferior to the actual C++ semantics.

Another alternative, used in some languages, is that the base ctors
and dtors are not run automatically. The derived class ctor/dtor specifies
the complete order of execution. This gives you the control you need to
let the above example work, but it also means, it seems to me, that the
derived class must know all about all its base classes. You lose the
modularity of needing to know only the interface of the base class. Any
change in any base class might require that you rewrite ctors and dtors
of derived classes. Some people think this model still provides an overall
advantage. I don't agree, but in any case, it isn't C++.

---
Steve Clamage, stephen.clamage@eng.sun.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. ]

keagchon@mehta.anu.edu.au (Geoff Keating 9205156) writes:

>The draft WP says that [section class.cdtor:3]

>  When  a  virtual function is called directly or indirectly from a con-
>  structor (including from its ctor-initializer) or from  a  destructor,
>  and the object to which the call applies is the object under construc-
>  tion or destruction, the function called is the  one  defined  in  the
>  constructor  or destructor's own class or in one of its bases, but not
>  a function overriding it in a class derived from  the  constructor  or
>  destructor's  class, or overriding it in one of the other base classes
>  of the complete object (_intro.object_).

>Why allow this, rather than refusing calls to virtual functions at
>all? It would be nice to say that `if I override this function, then
>the old version will _never_ be called on objects of this type'.

In general the compiler CANNOT diagnose a call to a virtual function
from a constructor or destructor - the call might very well come from
a non-virtual function in a separate compilation unit.

In view of this, the specification in the standard that the virtual
function call be treated as if the actual object were of the type of
the constructor or desctructor currently being executed is certainly
within reason.
-- 
** The Klingons' favorite food was named by the first earthling to see it **
David Sachs - Fermilab, HPPC MS369 - P. O. Box 500 - Batavia, IL 60510
Voice: 1 708 840 3942      Deparment Fax: 1 708 840 3785
---
[ 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. ]

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

fjh@munta.cs.mu.OZ.AU (Fergus Henderson) writes:

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

I disagree, and it would be a dangerous language rule, as I argue below.

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

But how do you know, given a set of library classes supplied in binary
form, what virtual functions are called from which constructors and
destructors? When I write a class, how do I know what classes will
someday be derived from it, and what future virtual functions might be
safe to call from my class's constructors and destructor?

Suppose the class library I acquire describes the virtual functions
called from each ctor/dtor. I make a check list to be sure that
any overriding virtual functions are safe to call from the base
class. Someone else now derives from my class, and has to combine
the data from all the base classes to figure out which new
overrides might be called from some base class ctor/dtor.

Now version 2 of the library class is released. Implementation
details of some constructors and destructors have changed. I have
to revise my checklist of virtual functions (and so do users
of my classes) to be sure any virtual functions that were not
previously called, but are called now, are safe.

You LIKE this as the required design procedure? That every class
must know the implementation details of all the constructors and
destructors of each of its base classes?


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

I think you would have to add this feature, or else disallow
virtual calls from constructors and destructors.

--
Steve Clamage, stephen.clamage@eng.sun.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. ]

>>>>> "SC" == Steve Clamage <clamage@Eng.Sun.COM> writes:
[...]
SC> But how do you know, given a set of library classes supplied in binary
SC> form, what virtual functions are called from which constructors and
SC> destructors? When I write a class, how do I know what classes will
SC> someday be derived from it, and what future virtual functions might be
SC> safe to call from my class's constructors and destructor?

True, but that is always the case with virtual functions. If you don't
want overriding outside your control, there are other options for that
(e.g., a virtual call to a private hierarchy of helper classes). If you
don't want overriding at all; you can always fully qualify the call.

SC> Suppose the class library I acquire describes the virtual functions
SC> called from each ctor/dtor. I make a check list to be sure that
SC> any overriding virtual functions are safe to call from the base
SC> class. Someone else now derives from my class, and has to combine
SC> the data from all the base classes to figure out which new
SC> overrides might be called from some base class ctor/dtor.
[...]

It would probably be a poorly designed library. Most reasonable
techniques I can imagine with virtual calls from a constructor would be
that the call resolves to the full object which is then reponsible
to relay-call the same function its base components.

What was the argumentation that lead to give defined semantics to
calls to virtual functions in constructors?

[...]
SC> I think you would have to add this feature, or else disallow
SC> virtual calls from constructors and destructors.

Right now, I think it makes sense disallowing them.

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

In article <470gvp$i3h@engnews1.eng.sun.com> clamage@Eng.Sun.COM (Steve Clamage) writes:

> [discussion about calling virtual function in derived classes from base class
> constructor deleted]
>
> >fjh@munta.cs.mu.OZ.AU (Fergus Henderson) writes:
> >[...]
> >Yes.  In fact I think that would *often* be the effect you want.
>
> I disagree, and it would be a dangerous language rule, as I argue below.

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.

The main problem with calling virtual functions in constructors is that the
complete object hasn't been fully initialized at the point of the call. 
However, isn't that a logical problem only if you really have access to 
the (sub-)object in that function? What if there was a type of member 
function with access only to static members and no implicit object pointer 
(just like an ordinary static member function), but which could be called 
through the virtual function table? Something like:

class B {
	int i;
public:
	static virtual int init() { return 1; } // not C++, but what if?
	B() : i(init()) {}
};

class D : public B {
public:
	static virtual int init() { return 2; }
};

B b; // B::B calls B::init which sets b.i to 1
D d; // B::B calls D::init which sets d.i to 2

Of course, the algorithms "return 1" and "return 2" here are so simple that 
you would write them directly in the colon list of B::B and D::D, but 
for more complicated code this would be convenient.

---
Harald Winroth
Computational Vision and Active Perception Laboratory,
Royal Institute of Technology, Stockholm.


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

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.

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.
-- 
Robert Martin       | Design Consulting   | Training courses offered:
Object Mentor Assoc.| rmartin@oma.com     |   OOA/D, C++, Advanced OO
2080 Cranbrook Rd.  | Tel: (708) 918-1004 |   Mgt. Overview of OOT
Green Oaks IL 60048 | Fax: (708) 918-1023 | Development Contracts.
---
[ 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. ]

clamage@Eng.Sun.COM (Steve Clamage) writes:

>fjh@munta.cs.mu.OZ.AU (Fergus Henderson) writes:
>
>>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.
>
>But how do you know, given a set of library classes supplied in binary
>form, what virtual functions are called from which constructors and
>destructors?

You read the documentation.

Actually, the important information you want to know is not
which virtual functions *are* called form ctors or dtors,
but rather which virtual functions *might* be called from ctors
or dtors; this distinction is important, because it allows
the implementation of the ctor to be changed without
having to change the class interface.

>When I write a class, how do I know what classes will
>someday be derived from it, and what future virtual functions might be
>safe to call from my class's constructors and destructor?

You document which functions might need to be called from ctors
or dtors.

You don't need to know in advance what classes will be derived from your
class.  You do need to use a "programming-by-contract" model.

>Suppose the class library I acquire describes the virtual functions
>called from each ctor/dtor.

Right.  In most cases this will be "none".

>I make a check list to be sure that
>any overriding virtual functions are safe to call from the base
>class. Someone else now derives from my class, and has to combine
>the data from all the base classes to figure out which new
>overrides might be called from some base class ctor/dtor.

What they have to do is implement the virtual functions in such
a way that each virtual function satisfies its contract.
This means that they must actually read the documentation for each
virtual function before defining it.

But they will have to do that anyway, won't they?

>Now version 2 of the library class is released. Implementation
>details of some constructors and destructors have changed. I have
>to revise my checklist of virtual functions (and so do users
>of my classes) to be sure any virtual functions that were not
>previously called, but are called now, are safe.

If you have changed which virtual functions might be called from a ctor
or dtor, then the change is not just a change to the implementation of
that ctor or dtor, it is also a change to the interface of the virtual
function.  As usual, weakening the preconditions on a virtual function
requires checking every implementation of that function.

>You LIKE this as the required design procedure?

I like design-by-contract.  If you follow design-by-contract,
I don't see why this causes any more difficulty than already exists.

>That every class
>must know the implementation details of all the constructors and
>destructors of each of its base classes?

No, that was not what I was suggesting.
I was suggesting that for each virtual function which 
might be called from a ctor or dtor, this fact should
be noted as part of the contract which that virtual
function must satisfy.

>>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.
>
>I think you would have to add this feature, or else disallow
>virtual calls from constructors and destructors.

I don't see why this particular instance of programming-by-contract
is so much more difficult than the many existing instances.
Programmers *already* have to make sure that virtual functions
satisfy their contract, otherwise their programs won't work.

It is already the case that virtual functions can be called in
situations when the class invariant doesn't hold.  (Think about it a
bit.)  So programmers already need to specify which virtual functions
might be called when the class invariant doesn't hold.  Why would
allowing functions to be called from ctors and dtors would make the
situation any worse than it already is?

	Fergus (in devil's advocate mode ;-).

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

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

In <1995Oct31.171443.3987@oma.com>, rmartin@oma.com (Robert Martin) writes:
>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.

Mr. Martin,
  This would not be "untennable" if the derived class functions that
could be called were limited to static member functions, as Mr. Winroth
proposed.  I would appreciate your insights into this matter once you
have taken that detail into account.  Thank you.

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

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