Topic: Why isn't `&Derived: :virt' a `void(Base::*)()'?


Author: rfg@netcom.com (Ronald F. Guilmette)
Date: Wed, 9 Jun 1993 07:20:22 GMT
Raw View
In article <9316012.25875@mulga.cs.mu.OZ.AU> fjh@munta.cs.mu.OZ.AU (Fergus James HENDERSON) writes:
+solomon@gjetost.cs.wisc.edu (Marvin Solomon) writes:
+
+>While we're on the subject, he're my favorite "so you think you knew C++"
+>question.
+>    struct Base1 { virtual void foo(); }
+>    struct Base2 { void foo(); }
+>    struct Derived : Base1, Base2 { void foo(); }
+>
+>Is Derived::foo virtual?  Please cite chapter and verse from the ARM (or
+>the ANSI standard :-) to support your answer.
+
+Yes. Section 10.2 says
+
+ "If a class `base' contains a `virtual' function `vf', and a
+ class `derived' derived from it also contains a function `vf'
+ of the same type, then ... The derived class function is said
+ to *override* the base class function."
+
+and later
+
+ "An overriding function is itself considered virtual".
+
+Thus for `base'==Base1, `vf'==foo, and `derived'==Derived we have can
+conclude that Derived::foo is said to override Base::foo, so
+Derived::foo is an overriding function, and hence it is considered
+virtual.

By a strict reading of the ARM, you might be correct, but I don't believe
that alone is sufficient to resolve the question.

In other words, I think you have oversimplified the issue.

--

// Ron ("Loose Cannon") Guilmette    uucp: ...uunet!lupine!segfault!rfg
//
//      "On the one hand I knew that programs could have a compelling
//       and deep logical beauty, on the other hand I was forced to
//       admit that most programs are presented in a way fit for
//       mechanical execution, but even if of any beauty at all,
//       totally unfit for human appreciation."
//                                              -- Edsger W. Dijkstra




Author: fjh@munta.cs.mu.OZ.AU (Fergus James HENDERSON)
Date: Sun, 6 Jun 1993 11:58:14 GMT
Raw View
jamshid@emx.cc.utexas.edu (Jamshid Afshar) writes:

>I guess I should have made it more clear that I was only discussing
>virtual functions that are defined in the base class (not those
>introduced in the derived class).  It just seems more logical to me
>that &Foo::virt should be of type "pointer to member of T" where T is
>the class that "first" declares the virtual function (instead of the
>"last" one to override it).

What about multiple inheritance?

 struct Base1 { virtual void foo(); }
 struct Base2 { virtual void foo(); }
 struct Derived : Base1, Base2 { virtual void foo(); }

Which is the "first" class to declare foo()?

--
Fergus Henderson                     This .signature virus might be
fjh@munta.cs.mu.OZ.AU                getting old, but you still can't
                                     consistently believe it unless you
Linux: Choice of a GNU Generation    copy it to your own .signature file!




Author: fjh@munta.cs.mu.OZ.AU (Fergus James HENDERSON)
Date: Wed, 9 Jun 1993 02:49:58 GMT
Raw View
solomon@gjetost.cs.wisc.edu (Marvin Solomon) writes:

>While we're on the subject, he're my favorite "so you think you knew C++"
>question.
>    struct Base1 { virtual void foo(); }
>    struct Base2 { void foo(); }
>    struct Derived : Base1, Base2 { void foo(); }
>
>Is Derived::foo virtual?  Please cite chapter and verse from the ARM (or
>the ANSI standard :-) to support your answer.

Yes. Section 10.2 says

 "If a class `base' contains a `virtual' function `vf', and a
 class `derived' derived from it also contains a function `vf'
 of the same type, then ... The derived class function is said
 to *override* the base class function."

and later

 "An overriding function is itself considered virtual".

Thus for `base'==Base1, `vf'==foo, and `derived'==Derived we have can
conclude that Derived::foo is said to override Base::foo, so
Derived::foo is an overriding function, and hence it is considered
virtual.

--
Fergus Henderson                     This .signature virus might be
fjh@munta.cs.mu.OZ.AU                getting old, but you still can't
                                     consistently believe it unless you
Linux: Choice of a GNU Generation    copy it to your own .signature file!