dove@rocket.uucp (Webster &) (08/01/90)
That way a user will write a definition for the body of a derived
class virtual function without declaring it in the derived class
definition. The derived class declaration element for the virtual
function is then inherited from an ancestral base class and the
inherited declaration and explicit definition MUST MATCH or a compile
time error occurs.
This would be substantially better than the current situation in which
given a mistaken difference between the intended base class virtual
function calling sequence and the actual derived class calling
sequence you just end up with a new virtual function at the level of
the derived class with no warning whatever about potential
misbehavior.
This is problem with a substantial probability of occurance since I
have seen this situation occur independently to two different
InterViews users.
This approach will save people who use public libraries from getting
shafted when a minor change happens in the calling syntax of some
virtual during a library update.
This approach will save people who misdefine the virtual definition in
a minor way.
This approach will be backward compatible, since redeclaration of the
virtual function in the derived class definition will have no effect.
Web
--
Dr. Webster Dove Dr. Webster Dove
Experimental Computing Systems ('X') Lockheed Sanders Inc.
Signal Processing Center of Technology 144 Daniel Webster Hwy.
Lockheed Sanders Inc. Merrimack, NH. 03054
email:
(usenet) ...!uunet!rocket!dove
(or internet) <rocket!dove@uunet.uu.net>jbuck@galileo.berkeley.edu (Joe Buck) (08/02/90)
In article <DOVE.90Jul31222153@rocket.uucp>, dove@rocket.uucp (Webster &) writes: |> That way a user will write a definition for the body of a derived |> class virtual function without declaring it in the derived class |> definition. The derived class declaration element for the virtual |> function is then inherited from an ancestral base class and the |> inherited declaration and explicit definition MUST MATCH or a compile |> time error occurs. You've neglected to say what happens if I have class Base { ... virtual void foo(); } class Derived : public Base { ... } and do not define void Derived::foo(). Currently, no problem; Base::foo() is used. Under your system, how can we know this? Your system seems to expect to use a Derived::foo() to be defined. Won't the linker report an undefined symbol? This is a real issue though; it's one of the things that most frequently burns me in C++ development. That's because the keyword virtual may mean two things: define a new virtual function that applies from this point in the class hierarchy downwards, OR override the baseclass definition of this function, as follows. There's no way to unambiguously specify one or the other. An off-the-wall idea I don't expect to be accepted: allow the following syntax: class Derived : public Base { virtual foo; } That's right; omit the types. This means that class Derived intends to override all virtual functions of the baseclass that are named foo. This is analogous to the following existing C++ notation: class Base { ... public: int func1(int,char*); ... } class Derived: private Base { ... public: Base::func1; // make func1 public for class Derived ... } Here again, you omit the type and arguments to the member function. If the "virtual foo;" notation is used, it is required that a void Derived::foo() is defined or you get an undefined symbol. |> This would be substantially better than the current situation in which |> given a mistaken difference between the intended base class virtual |> function calling sequence and the actual derived class calling |> sequence you just end up with a new virtual function at the level of |> the derived class with no warning whatever about potential |> misbehavior. |> |> This is problem with a substantial probability of occurance since I |> have seen this situation occur independently to two different |> InterViews users. |> |> This approach will save people who use public libraries from getting |> shafted when a minor change happens in the calling syntax of some |> virtual during a library update. |> |> This approach will save people who misdefine the virtual definition in |> a minor way. |> |> This approach will be backward compatible, since redeclaration of the |> virtual function in the derived class definition will have no effect. |> |> Web |> -- |> Dr. Webster Dove Dr. Webster Dove |> Experimental Computing Systems ('X') Lockheed Sanders Inc. |> Signal Processing Center of Technology 144 Daniel Webster Hwy. |> Lockheed Sanders Inc. Merrimack, NH. 03054 |> |> email: |> (usenet) ...!uunet!rocket!dove |> (or internet) <rocket!dove@uunet.uu.net> -- Joe Buck jbuck@galileo.berkeley.edu {uunet,ucbvax}!galileo.berkeley.edu!jbuck
rfg@NCD.COM (Ron Guilmette) (08/04/90)
In article <37923@ucbvax.BERKELEY.EDU> jbuck@galileo.berkeley.edu (Joe Buck) writes: >This is a real issue though; it's one of the things that most frequently >burns me in C++ development. That's because the keyword virtual may >mean two things: define a new virtual function that applies from this >point in the class hierarchy downwards, OR override the baseclass definition >of this function... Wrong. I don't know where you got this strange idea about your hypothetical second meaning for "virtual", but it is wrong. A member function in a derived class always overrides a member function with the same name and parameter-list-profile in the base class(es). That occurs independently on whether or it is is also declared virtual. -- // Ron Guilmette // C++ Entomologist // Internet: rfg@ncd.com uucp: ...uunet!lupine!rfg // Motto: If it sticks, force it. If it breaks, it needed replacing anyway.
dove@rocket.uucp (Webster &) (08/06/90)
In article <37923@ucbvax.BERKELEY.EDU> jbuck@galileo.berkeley.edu (Joe Buck) writes: From: jbuck@galileo.berkeley.edu (Joe Buck) Date: 1 Aug 90 22:51:36 GMT In article <DOVE.90Jul31222153@rocket.uucp>, dove@rocket.uucp (Webster &) writes: |> That way a user will write a definition for the body of a derived |> class virtual function without declaring it in the derived class |> definition. The derived class declaration element for the virtual |> function is then inherited from an ancestral base class and the |> inherited declaration and explicit definition MUST MATCH or a compile |> time error occurs. You've neglected to say what happens if I have class Base { ... virtual void foo(); } class Derived : public Base { ... } and do not define void Derived::foo(). Currently, no problem; Base::foo() is used. Under your system, how can we know this? Your system seems to expect to use a Derived::foo() to be defined. Won't the linker report an undefined symbol? No, the body of the function member will be inherited just as the declaration was unless one or the other is overridden in this derived class. In essence all I am suggesting is that virtual function member specifications (inside the class specification) be optionally inheritable just as body definitions currently are. If the writer intends to use an inherited virtual function member spec (my case), they just write the body. Failure to match the inherited virtual spec causes a compiler error. If they want to inherit both the spec and the body (as in your case) they need only do what you did. This is a real issue though; it's one of the things that most frequently burns me in C++ development. That's because the keyword virtual may mean two things: define a new virtual function that applies from this point in the class hierarchy downwards, OR override the baseclass definition of this function, as follows. There's no way to unambiguously specify one or the other. In the current language there is no need to use the word virtual if you are overriding the inherited definition only if you are starting a new virtual at the new level. Note that once a function/args pair has been spec'd as virtual it remains virtual for all offspring. The only thing that redeclaration of the spec can do for you is change whether the function member is public (ignoring the fact that you must currently put in the spec whether you need it or not). Web -- Dr. Webster Dove Dr. Webster Dove Experimental Computing Systems ('X') Lockheed Sanders Inc. Signal Processing Center of Technology 144 Daniel Webster Hwy. Lockheed Sanders Inc. Merrimack, NH. 03054 email: (usenet) ...!uunet!rocket!dove (or internet) <rocket!dove@uunet.uu.net>
dove@rocket.uucp (Webster &) (08/06/90)
From: uunet!iad-nxe.global-mis.dhl.com!elw (Edwin Wiles)
Subject: Re: Can we allow virtual function member declarations to be inherited?
In article <DOVE.90Jul31222153@rocket.uucp> you write:
>That way a user will write a definition for the body of a derived
>class virtual function without declaring it in the derived class
>definition. The derived class declaration element for the virtual
>function is then inherited from an ancestral base class and the
>inherited declaration and explicit definition MUST MATCH or a compile
>time error occurs.
Nice idea... Though without the explicit definition in the derived
class, how can you be certain that that was what the author of the
derived class wanted? Having things happen "automagically" is a good
way to get non-gurus terribly confused.
Right now you have no way of saying that you want to inherit the
fun/arg spec for the function member. Once you put a fun/arg spec in
your derived class spec, if the ancester virtual goes away because of
a library change, the compiler will still be happy making you a new
function member starting with your current class. By allowing the
writer to (optionally) inherit the spec, you give the writer a way to
express his intentions to the compiler without rendering any old code
invalid.
>This would be substantially better than the current situation in which
>given a mistaken difference between the intended base class virtual
>function calling sequence and the actual derived class calling
>sequence you just end up with a new virtual function at the level of
>the derived class with no warning whatever about potential
>misbehavior.
When a base class virtual function has a mismatch between it and a
derived class virtual function of the same name, it should at least
generate a warning at compile time. If it isn't doing that, then I'd
say the compiler/interpreters are falling down on the job.
This solution has some merits and some problems. It is better than
the current situation (I don't believe g++-1.37.1 which I have been
using does this). However, if the writer does intend to start a new
fun/arg in his current derived class (one that matches the function,
but not the arguments of any ancestral spec), won't the compiler
complaint at him?
Web
--
Dr. Webster Dove Dr. Webster Dove
Experimental Computing Systems ('X') Lockheed Sanders Inc.
Signal Processing Center of Technology 144 Daniel Webster Hwy.
Lockheed Sanders Inc. Merrimack, NH. 03054
email:
(usenet) ...!uunet!rocket!dove
(or internet) <rocket!dove@uunet.uu.net>cline@cheetah.ece.clarkson.edu (Marshall Cline) (08/16/90)
In article <1069@lupine.NCD.COM> rfg@NCD.COM (Ron Guilmette) writes: >In article <37923@ucbvax.BERKELEY.EDU> jbuck@galileo.berkeley.edu (Joe Buck) writes: >>...the keyword virtual may >>mean two things: define a new virtual function that applies from this >>point in the class hierarchy downwards, OR override the baseclass definition >>of this function... >Wrong. I don't know where you got this strange idea about your hypothetical >second meaning for "virtual", but it is wrong. I suspect ``where he got this strange idea'' was that most redefined functions are virtual in the base class. I hate to put words in Joe's mouth, but my guess is that he was saying ``virtual can mean to virtualize a previously non-virtual in a base class.'' I'd like to make an appeal: let's keep the C++ newsgroups friendly. (I know this doesn't apply to Joe Buck, but...) There are many many many new C++ers. This is a good problem to have! The X newsgroup has a `rep' for flaming beginners; that's a rep we don't need or want. -- ============================================================================== Marshall Cline / Asst.Prof / ECE Dept / Clarkson Univ / Potsdam, NY 13676 cline@sun.soe.clarkson.edu / Bitnet:BH0W@CLUTX / uunet!clutx.clarkson.edu!bh0w Voice: 315-268-3868 / Secretary: 315-268-6511 / FAX: 315-268-7600 Career search in progress; ECE faculty; research oriented; will send vita. PS: If your company is interested in on-site C++/OOD training, drop me a line! ==============================================================================
rfg@NCD.COM (Ron Guilmette) (08/16/90)
In article <CLINE.90Aug15132637@cheetah.ece.clarkson.edu> cline@sun.soe.clarkson.edu (Marshall Cline) writes: >In article <1069@lupine.NCD.COM> rfg@NCD.COM (Ron Guilmette) writes: >>In article <37923@ucbvax.BERKELEY.EDU> jbuck@galileo.berkeley.edu (Joe Buck) writes: > >I'd like to make an appeal: let's keep the C++ newsgroups friendly. (I know >this doesn't apply to Joe Buck, but...) There are many many many new C++ers. >This is a good problem to have! The X newsgroup has a `rep' for flaming >beginners; that's a rep we don't need or want. Point well taken. My apologies to Joe and anyone else I may have offended. -- // Ron Guilmette - C++ Entomologist // Internet: rfg@ncd.com uucp: ...uunet!lupine!rfg // Motto: If it sticks, force it. If it breaks, it needed replacing anyway.