🚀 go-pugleaf

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