Path: utzoo!attcan!uunet!snorkelwacker!usc!zaphod.mps.ohio-state.edu!sdd.hp.com!hplabs!hpda!hpcupt1!jamiller
From: jamiller@hpcupt1.HP.COM (Jim Miller)
Newsgroups: comp.lang.c++
Subject: Re: Will C++ 2.1 fix the virtual function linkage problem?
Message-ID: <7050017@hpcupt1.HP.COM>
Date: 6 Jun 90 21:30:32 GMT
References: <DOVE.90Jun2102921@batman.uucp>
Organization: Hewlett Packard, Cupertino
Lines: 65

>I agree that this is a big problem with C++, but your proposed solution
>seems weird.  Explicitly state by omission?  What does the derived class
>do if it doesn't want to re-define the function?  Or if it wants to
>define a totally different function that happens to have the same name?
>
>How about if the derived class can declare that it will be re-defining a
>virtual function without having to re-state the type and arguments of
>the function?  Like this:
>
>class derived_class : public base_class {
>	base_virtual;
>}
>
>  Jef Poskanzer  jef@well.sf.ca.us  {ucbvax, apple, hplabs}!well!jef
>             "She's not a woman -- she's the Terminator!"
>

As noted, overloading would give problems if you do not give the type of
arguments.  It seems to me that I want to redefine a routine I should give
the same parameters, but the compiler should help me make sure that the
base virtual function has not changed it's parameters.  

I want to introduce a new keyword (oh, no, not another!): "virtual+".
Virtual+ says that it is replacing a virtual function from an inherited
class.  If there is no match, the compiler gives and error.

"virtual-" might be also introduced, meaning this function is NOT supposed
to replace a base function (at least it didn't when I wrote it...).


class base_class {
public:
        virtual base_virtual();
};

int base_class::base_virtual() { ... default behavior ... }


class derived_class : public base_class {
        virtual+  base_virtual();  // name and parms must match exactly!
               ^****
}

int derived_class::base_virtual() { ... derived behavior ... }


I think this would solve the "but the library changed and never told me"
problem.  It should be completely compatible with existing code.

I would think that I would have to know EXACTLY the parameters of the
routine I'm trying to replace in my new function.  Yes, there would
be still gotcha's.  If you are counting on type conversion, then the base
class includes a new function by the same name that now has the right
types.  In that case your derived function would not get called
after type conversion, the new function would get called without any
type conversion.  However, by doing explicit type conversion you could
write your code so that it would call the correct routine no matter
what the base class did.  

This mechanism would allow one to program more defensively than is
now possible.

      jim - $.02 - miller

   These opinions are not necessarily those of the company I work for.