mcf@tardis.trl.OZ.AU (Michael Flower) (05/08/91)
I have come across something that appears strange.
If I compile the following with the AT&T 2.1 C++ compiler:
class A {
virtual void fn(char); // 1
virtual void fn(char *); // 2
};
class B : public A {
void fn(int);
};
main() {}
in the following way, I get.
"t.c", line 7: warning: B::fn() hides virtual A::fn()
"t.c", line 7: warning: B::fn() hides virtual A::fn()
Of course B::fn() hides A::fn(). That is why I wrote it! After all A::fn() is
virtual.
If I change the order of lines 1 and 2 (in class A), the problem goes away.
Admittedly it is only a warning, but I don't like warnings, they often spell
trouble. Is this an anomally?
Michael Flower
Artificial Intelligence Systems Email: m.flower@trl.oz.au
Telecom Research Laboratories Voice: +61 3 541 6179
Melbourne, AUSTRALIA Fax: +61 3 543 8863steve@taumet.com (Stephen Clamage) (05/08/91)
mcf@tardis.trl.OZ.AU (Michael Flower) writes: >class A { > virtual void fn(char); // 1 > virtual void fn(char *); // 2 >}; >class B : public A { > void fn(int); >}; >"t.c", line 7: warning: B::fn() hides virtual A::fn() >"t.c", line 7: warning: B::fn() hides virtual A::fn() >Of course B::fn() hides A::fn(). That is why I wrote it! After all A::fn() is >virtual. >If I change the order of lines 1 and 2 (in class A), the problem goes away. This is a compiler bug, but not in the way you think. You should always get the warning. B::fn(int) hides (not overrides) both A::fn(char) and A::fn(char*) in that neither function is implicitly accessible from a B object. A virtual function in a derived class overrides (not hides) one in a base class if the signatures are the same (and the return types must match as well). In what you show, B::fn(int) is not virtual. So with your code we can get the following: B b; b.fn(2); // calls B::fn(int) b.fn('c'); // calls B::fn((int)'c'), not A::fn('c') b.fn("hello"); // illegal But you could still do this: b.A::fn('c'); // calls A::fn(char) b.A::fn("hello"); // calls A::fn(char*) If you declare B::f(int) explicitly virtual, you will get: b.fn(2); // calls B::fn(int) b.fn('c'); // calls A::fn(char) b.fn("hello"); // calls A::fn(char*) -- Steve Clamage, TauMetric Corp, steve@taumet.com
sdm@cs.brown.edu (Scott Meyers) (05/09/91)
In article <718@taumet.com> steve@taumet.com (Stephen Clamage) writes: | mcf@tardis.trl.OZ.AU (Michael Flower) writes: | | >class A { | > virtual void fn(char); // 1 | > virtual void fn(char *); // 2 | >}; | >class B : public A { | > void fn(int); | >}; ... | A virtual function in a derived class overrides (not hides) one | in a base class if the signatures are the same (and the return types | must match as well). ... | If you declare B::f(int) explicitly virtual, you will get: | b.fn(2); // calls B::fn(int) | b.fn('c'); // calls A::fn(char) | b.fn("hello"); // calls A::fn(char*) Nope, even when B::fn is virtual, it still hides the two versions of A::fn: b.fn(2); // calls B::fn(int) b.fn('c'); // calls B::fn(int) b.fn("hello"); // illegal Remember that overloaded functions are disambiguated statically, and the scope of B hides the scope of A. Hence all references to the identifier fn through an object of (static) type B will resolve to the fn in B's scope. Scott ------------------------------------------------------------------------------- What do you say to a convicted felon in Providence? "Hello, Mr. Mayor."
bobj@gli.com (Robert Jacobs) (05/09/91)
Michael Flower writes. > If I compile the following with the AT&T 2.1 C++ compiler: > > class A { > virtual void fn(char); // 1 > virtual void fn(char *); // 2 > }; > > class B : public A { > void fn(int); > }; > > main() {} > > in the following way, I get. > > "t.c", line 7: warning: B::fn() hides virtual A::fn() > "t.c", line 7: warning: B::fn() hides virtual A::fn() > > Of course B::fn() hides A::fn(). That is why I wrote it! After all A::fn() is > virtual. > ..... In the ARM on page 210 Stroustrup writes: C++ requires an exact type match between a virtual function in a base class and a function overriding it in a derived class. In other words, for a function to be virtual in respect to its base class, it must match in: 1) return type 2) argument types int != char != char* Hence the reason for the warning. fn(int) is not a virtual function. -------------------------------------------------------------------------- Robert Jacobs bobj@gli.com
jimad@microsoft.UUCP (Jim ADCOCK) (05/10/91)
In article <3472@trlluna.trl.oz> mcf@tardis.trl.OZ.AU (Michael Flower) writes: |I have come across something that appears strange. | |class A { | virtual void fn(char); // 1 | virtual void fn(char *); // 2 |}; | |class B : public A { | void fn(int); |}; | |main() {} | |in the following way, I get. | |"t.c", line 7: warning: B::fn() hides virtual A::fn() |"t.c", line 7: warning: B::fn() hides virtual A::fn() | |Of course B::fn() hides A::fn(). That is why I wrote it! After all A::fn() is |virtual. | |If I change the order of lines 1 and 2 (in class A), the problem goes away. |Admittedly it is only a warning, but I don't like warnings, they often spell |trouble. Is this an anomally? I think a C++ compiler *ought* to emit a warning when someone overrides a virtual function with a non-virtual function in a derived class with a public base. Do you realize that B::fn(int) is non-virtual? Maybe the warning ought to be: warning: B::fn() only *partially* hides virtual A::fn() [The order you declare things in A shouldn't matter in this issue -- if a compiler is going to issue a warning it should apply no matter what the ordering of declarations in class A.] Here's why I think you deserve [at least] a warning for what you've done: In class A you've declared a virtual fn(char) that you're stating is part of a polymorphic interface. When you've publicly inherited A in class B, you're stating a B can be used as either an A or a B. If something is polymorphic we expect its behavior to be the same when either accessed as a B or an A: B* bp = new B; A* ap = bp; bp->fn(5); ap->fn(5); And we'd expect the same behavior of fn(5) in either case -- because fn(5) *appears* to be a virtual function, by virtue of fn(?) being declared virtual in the base class. And bp and ap are just alternate names for the same object -- the object should interpret fn(5) message the same in either case. But in reality, the above is resolved as: bp->B::fn(5); // B's non-virtual fn(int) ap->A::fn(5); // A's virtual fn(char) so that the behavior of the B object depends on the type of pointer thru which fn(?) is invoked -- in spite of the fact that in A all flavors of fn(?) are declared virtual. One hardly expects this from a "polymorphic" class, so I think the warning is deserved. Consider the plight, for example, of a C++ programmer coming from the C world who hasn't complete absorbed the notion that char and int really are really distinct in C++, so that they accidentally declare B::fn(int) in the derived class, when they really intended to override the virtual method A::fn(char). Without the warning [or maybe even with it] they might spend a long, long time figuring out why they keep getting A::fn(char) when invoked as ap->fn(5) -- or alternatively why they keep getting B::fn(int) when invoked as bp->fn('A') !!! If in turn a class C is derived from class B, and some of the fn(?) are virtually/non-virtually overridden in C, then the situation becomes even worse. One proposal before the ANSI C++ committee would allow the use of ~virtual to allow a programmer to explicitly state that a method was intended to be non-virtual. In which case in B you could state: ~virtual fn(int); // Don't you warn me, I "know" what I'm doing! ---- I'd recommend that programmers not use functions overloaded by argument with polymorphic classes -- effectively you're doing double dispatch, but with the object type resolved dynamically, while the parameter types resolve statically, which leads to some pretty wierd combinations. But, if you insist on doing this, I think they better all be virtual, all be declared in the same base class, and all be re-implemented in any base class that overrides any one of them. ---- A simplified example of the problem: extern "C" printf(const char*, ...); class A { public: virtual void print(char c) { printf("as A prints(%c)\n", (int)c); } }; class B : public A { public: void print(int i) { printf("as B prints(%d)\n", i); } }; main() { B b; B* bp = &b; A* ap = &b; ap->print('A'); bp->print('A'); bp->print(11); ap->print(11); return 0; }
robert@kohlrabi.tcs.com (Robert Blumen) (05/10/91)
In article <3472@trlluna.trl.oz>, mcf@tardis.trl.OZ.AU (Michael Flower) writes: |> If I compile the following with the AT&T 2.1 C++ compiler: |> |> class A { |> virtual void fn(char); // 1 |> virtual void fn(char *); // 2 |> }; |> |> class B : public A { |> void fn(int); |> }; |> |> in the following way, I get. |> |> "t.c", line 7: warning: B::fn() hides virtual A::fn() |> "t.c", line 7: warning: B::fn() hides virtual A::fn() |> |> Of course B::fn() hides A::fn(). That is why I wrote it! After all A::fn() |> is virtual. The message means that B::fn hides A::fn() and the compiler is wondering whether perhaps you want B::fn to override A::fn() instead. I am not sure why the message goes away when you reverse 1. and 2. This may have something to do with what implicit type conversion gets performed. If you want B::fn() to override A::fn() for 1. or 2., you must declare it with exactly the same prototype. ----------------------------------------------------------------------------- Robert Blumen | rblumen@tcs.com Senior Software Engineer | 2121 Allston Way, Berkeley, CA 94704 Teknekron Communications Systems, Inc. | (415) 649-3759