In article <20012@alice.att.com> bs@alice.att.com (Bjarne Stroustrup) writes:
|I think you meant
|
| class Derived : Base {
|  virtual double foo() const;
| };
|
|In that case cfront 2.0 warns:
|
|"", line 5: warning:  Derived::foo() hides virtual Base::foo()

It seems to me a warning message represents a disagreement between
a language specification and a compiler specification.  If a feature
ought to be in a language, it ought to be accepted by compilers
without warning.  Warnings might be appropriate when a programmer depends
on implementation dependent features, but why otherwise?

ngo@tammy.harvard.edu (Tom Ngo @ Harvard Chemistry Department) writes

 > The opposite thing has also happened to me:  in a derived class I have
 > meant for a function to be virtual, but because of a minor difference
 > in declaration the method in the derived class has created a new vtbl
 > entry instead of filling in one declared in its base class.  For
 > example:
 >
 >     class Base {
 >        virtual double foo();
 >     };
 >     class Derived {
 >         virtual double foo() const;
 >    };
 >
 > Could once think of some protection against this sort of error?

I think you meant

 class Derived : Base {
  virtual double foo() const;
 };

In that case cfront 2.0 warns:

"", line 5: warning:  Derived::foo() hides virtual Base::foo()

Jim Adcock <jimad@microsoft.UUCP> wrote:

jimad> Regards ~virtual:
jimad>
jimad> Also note, under today's system, where a derived class cannot
jimad> explicitly declare a method ~virtual, the possibility exists
jimad> for a base class programmer to "hijack" a private derived class
jimad> method by declaring it public virtual in the base class. [...]

Excellent point.  This has happened to me more than once, particularly
with the very common virtual function names Draw() and Update()!

The opposite thing has also happened to me:  in a derived class I have
meant for a function to be virtual, but because of a minor difference
in declaration the method in the derived class has created a new vtbl
entry instead of filling in one declared in its base class.  For
example:

    class Base {
        virtual double foo();
    };
    class Derived {
        virtual double foo() const;
    };

Could once think of some protection against this sort of error?

I like the idea of using ~virtual to protect against the first kind of
error.  These semantics FEEL like those of ~const, even though the
parallel is not perfect (~virtual is a property of a method, whereas
the effects of ~const must be determined separately for each object of
a class).

--
  Tom Ngo
  ngo@harvard.harvard.edu
  617/495-1768 lab number, leave message