🚀 go-pugleaf

In article 95Oct30130647@avs.cs.rpi.edu, vandevod@cs.rpi.edu (David Vandevoorde) writes:
>
>Or perhaps more generally: virtual calls on incompletely constructed
>objects are undefined. Hence the this-pointer could be exported by
>the constructor for storage purposes (and potential call after
>construction is finished). Would that do?

Let's restore some context. We were talking about changing the C++ object
model. Under the current model, calls to virtual functions are well-
defined from constructors and destructors: you get the same result as
if the constructor's (destructor's) type were the complete object.

If you want to change the object model so that when constructing a base
class, the derived-class virtual functions can get called, then a lot
of issues have to be resolved. I was pointing out one set of issues. I
don't think you want to address this object model change as a quick fix,
but look at the entire subject and define an object model that has all
the properties you want.

The current object model has these features:
1. Calls to virtual functions from ctors/dtors are well-defined.
2. Construction/destruction of base classes is fully automatic.
3. During construction/destruction, you always know the validity of the
   object; that is, the order of construction and destruction of members
   and bases is predefined.
4. When deriving a class, you need to know only the public and protected
   interface of base classes; you don't need to know any implementation
   details.

It seems to me that in order to allow calls to derived virtual overrides
from a base-class ctor/dtor you have to give up some of these features.
In designing the object model, you have to decide what features are
important, and what features you can do without. If you are going to
change the object model significantly, you might as well think about other
major changes and make a new language, IMHO. 
---
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. ]