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

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.

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>

    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>

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>

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