🚀 go-pugleaf

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	

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.

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>

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!
==============================================================================