🚀 go-pugleaf

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