🚀 go-pugleaf

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