~virtual (followup to ~const proposal 1.6)

Thread View: comp.std.c++

3 messages

[T] Back to Threads [V] Tree View [G] Group Articles

3 total messages Started by Tom Ngo Sat, 02 Mar 1991 06:46

#883

Author: Tom Ngo
Date: Sat, 02 Mar 1991 06:46

38 lines
1814 bytes

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

Re: ~virtual (followup to ~const proposal 1.6)

#911

Author: Bjarne Stroustrup
Date: Sun, 03 Mar 1991 13:43

28 lines
1237 bytes


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()

Re: ~virtual (followup to ~const proposal 1.6)

#941

Author: Jim ADCOCK
Date: Mon, 11 Mar 1991 23:27

16 lines
1077 bytes

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?

Thread Navigation

This is a paginated view of messages in the thread with full content displayed inline.

Messages are displayed in chronological order, with the original post highlighted in green.

Use pagination controls to navigate through all messages in large threads.

Back to All Threads