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

I might add the current object model does not preclude a coding style that
achieves the aims of the alternate.  Such a coding style isn't even contrived.
Just imagine, however, the contortions one might have to go through to develop
a coding style that simulated the current object model assuming the alternate
model was the standard.

--
John Hickin      Bell-Northern Research, Montreal, Quebec
(514) 765-7924   hickin@bnr.ca
---
[ 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. ]

"john (j.d.) hickin" <hickin@bnr.ca> writes:

>|> 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.
>
>I might add the current object model does not preclude a coding style that
>achieves the aims of the alternate.  Such a coding style isn't even contrived.

Am I right to suppose that you are talking about using an explicit create()
or init() function to perform initialization, rather than using the
constructor?

>Just imagine, however, the contortions one might have to go through to develop
>a coding style that simulated the current object model assuming the alternate
>model was the standard.

I've yet to come across an example for which this aspect of the current
object model is useful.  Has anyone else encountered one?


---
[ 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:

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

I disagree.  The current object model doesn't have feature 4.

When deriving a class, you need to know the contract that each
virtual function which you override must satisfy.

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

I disagree.  The only feature you need to give up is feature 4, but
since you never had that anyway, you haven't really lost anything.

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

On this I agree.  I don't think the C++ object model is optimal, but
I agree it would be a very bad idea to change it now.

--
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 <475jnr$1sv@engnews1.eng.sun.com>,
Steve Clamage <clamage@Eng.Sun.COM> wrote:
>
>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.

They are well-defined, but defined in such a way that is at best
confusing and error-prone (despite being consistent and predictable).
I recently got bit by this one in the form:

---
class A {
public:
    virtual void close() {
 cerr << "A::close()\n";
    }
    virtual ~A() {
 cerr << "~A()\n";
 close();
    }
};

class B : public A {
    void close() {
 cerr << "B::close()\n";
    }
};
---

The call to close() LOOKS like a normal call to a virtual function,
unless you remember that there is an 'exception' in the language for
this case.

A good compiler (g++ people listening? :-) ) should probably warn
about this call (or have the ability to warn about it) in this case.
The warning can be prevented by explicitly calling A::close() if that
is what is intended.

It obviously isn't possible to catch it in the general case, which
understandably makes people unwilling to introduce undefined behavior
where there currently is none.

As was pointed out in the rest of the post, it isn't possible to
successfully execute the virtual-ness, although that misses the
point.  One really wants to be warned about such things so that one
can fix them correctly (by adding a destructor to B, for example).
--
Tim Hollebeek      | Everything above is a true statement, for sufficiently
PChem Grad Student | false values of true.
Princeton Univ.    | C++ == OOP--
-------------------| tim@handel.princeton.edu  http://wagner.princeton.edu/~tim

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