Overriding overloaded functions in base classes

[Rick]

One of the rules I have recommended for our new coding standard is as
follows:

"When overriding a base class virtual function, all overloads of that
base class virtual function should also be overridden. Otherwise, the
overloads of the overridden function in the base class will not be
visible from the derived class."

In other words...

class foo
{
public:
virtual int abc( int def );
virtual int abc( char ghi, int jkl );
};

class bar : public foo
{
public:
int abc( int def ); // << override of first abc in base class
};

I claim that virtual int abc( char ghi, int jkl ) in class foo is now
invisible to class bar and its users, i.e.:

int w;
char x;
int y;
bar z;

w = z.abc( x, y );

.... will not work.

But, I can't find any reference in Stroustrup (or anywhere else, so
far) that supports that claim.

Am I right or wrong?

If I am right, then I have been asked to provide a reference to
something that supports it, so if any of you happen to know of a
reference I can use (preferably to Stroustrup) that would be much
appreciated.

Thanks...

 

[red floyd]

One of the rules I have recommended for our new coding standard is as
follows:

"When overriding a base class virtual function, all overloads of that
base class virtual function should also be overridden. Otherwise, the
overloads of the overridden function in the base class will not be
visible from the derived class."

In other words...

class foo
{
public:
virtual int abc( int def );
virtual int abc( char ghi, int jkl );
};

class bar : public foo
{
public:
int abc( int def ); // << override of first abc in base class
};

I claim that virtual int abc( char ghi, int jkl ) in class foo is now
invisible to class bar and its users, i.e.:

int w;
char x;
int y;
bar z;

w = z.abc( x, y );

... will not work.

But, I can't find any reference in Stroustrup (or anywhere else, so
far) that supports that claim.

Am I right or wrong?

If I am right, then I have been asked to provide a reference to
something that supports it, so if any of you happen to know of a
reference I can use (preferably to Stroustrup) that would be much
appreciated.

See FAQ 23.9.
http://www.parashift.com/c++-faq-lite/strange-inheritance.html#faq-23.9

 

[Kira Yamato]

See FAQ 23.9.
http://www.parashift.com/c++-faq-lite/strange-inheritance.html#faq-23.9

Ok. But what is the rational behind this? Why should functions in
derived classes hide those in base classes rather than just overloading
them?

I've been told over and over that a good trait of nice clean software
design is the principle of least surprise. I would've expected that if
a function is in the base class, then it should be visible in the
derived classes also.

 

[Alf P. Steinbach]

* Kira Yamato:

Ok. But what is the rational behind this? Why should functions in
derived classes hide those in base classes rather than just overloading
them?

I've been told over and over that a good trait of nice clean software
design is the principle of least surprise. I would've expected that if
a function is in the base class, then it should be visible in the
derived classes also.

The principle of least surprise works both ways.

You're envisioning an existing base class, someone deriving a new class,
and getting surprised.

Envision instead an existing derived class, someone modifying the base
class (by adding a new overload), and the derived class' programmerer
being surprised that his code now suddenly gives incorrect results.

Granted, that's less likely, but on the other hand it's more serious
because it's not the one modifying the code who is surprised, and the
change is silent.

So of these two possible surprises the current rules try to minimize the
second kind, the "fragile base class", that your derived class code that
depends on a given overload resolution should not be affected by
additions of simple overloads to a base class (unless you ask for it, in
which case that's your decision).


Cheers, & hth.,

- Alf

 

[Kira Yamato]

* Kira Yamato:

The principle of least surprise works both ways.

You're envisioning an existing base class, someone deriving a new
class, and getting surprised.

Envision instead an existing derived class, someone modifying the base
class (by adding a new overload), and the derived class' programmerer
being surprised that his code now suddenly gives incorrect results.

Granted, that's less likely, but on the other hand it's more serious
because it's not the one modifying the code who is surprised, and the
change is silent.

So of these two possible surprises the current rules try to minimize
the second kind, the "fragile base class", that your derived class code
that depends on a given overload resolution should not be affected by
additions of simple overloads to a base class (unless you ask for it,
in which case that's your decision).

Hmm... Very subtle. C++ truly has its subtleties. Designing a
language with advanced features isn't really an easy undertaking.