🚀 go-pugleaf

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