Well, the reason, which is given in the ARM, is that the overloading
mechanism functions within a single scope only. It really has nothing to do
with virtual functions at all. Consider:

void Foo( int i );

class A
{
public:
  void Foo( float f );
};

class B : public A
{
public:
  void Foo( double d );
  void Bar();
};

void B::Bar()
{
  int i;
  Foo( i );
}

In this example in B::Bar i will be promoted to a double, and B::Foo(
double) will be called. The overloading mechanism does not function, and
B::Foo hides the other two versions that are in scope. For a discussion of
the reasons see the ARM, section 13.1, pages 310,311. The basic argument is
that allowing overloading across scopes, particularly in a deep inheritance
hierarchy, can lead to unintended consequences.

--Mark Betz
---
[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

Colen Garoutte-Carson wrote:
>
> (Warning, flame potential)
>  Can anyone give me a _good_ reason in defense
> of this behavior?  <derived class function hides all base classes of same name>

Obviously not, if you get to define "good reason".  I will mention that
a simple using declaration solves your problem.

struct Base {
  void foo(int);
  void foo(double);
};

class SomeObject;
struct Derived : public Base {
  void foo(SomeObject);
  using Base::foo;
};

int main( )
{
  Derived d;
  d.foo(7); //calls Base::foo(int)
}

> Also, while I'm at it, why can you only declare a friend function within a
> class declaration?  What if the 'friendly' function is only used in one
> translation unit (where the class is implemented), so it would be
> preferable to make it 'static'?

Because if anyone can decide they're a friend of a class, you don't have
encapsulation any more.  Just put the word class between 'friend' and
the class name.

struct Base {
  void foo(int);
  void foo(double);
private:
  friend class NotInThisFile;
};
---
[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

(Warning, flame potential)

In the following situation:

class Sortable
{
public:
// returns node which takes it's place, if any

   virtual Sortable * remove(void);  // Removes 'this'

   // Removes s, if exists within/beneath/after 'this'
   virtual Sortable * remove(Sortable * s) = 0;

   // Calls a virtual Search routine which returns a Sortable
   //   then passes it to remove(Sortable*)
   virtual Sortable * remove(searchCriteria *srch);

// Much omited
};

class BTreeNode : public Sortable
{
public:
   virtual Sortable * remove(Sortable * s);

// Much omited
};


Why in the ... heck ... does BTreeNode::remove(Sortable * s) hide
Sortable::remove(void) and Sortable::remove(searchCriteria) ?!?!?!  (I
don't have an ARM handy)  Virtual function hiding puts a severe cramp in
my style.  I've argued C++ implementation specifics with the best of them
(in technical support for both Symantec and Metrowerks), but I can see no
reason way this behavior should be desirable, short of vague opinions on
strict programming style, and to keep people who don't know what they're
doing from making mistakes.  Can anyone give me a _good_ reason in defense
of this behavior?  I've talked to many of my co-workers, and haven't found
one.  In fact, this seems to be one of our biggest perceived flaws in C++,
and we've had to design around it.  Is there any hope of ever getting this
changed?  It makes creating a family of overloaded virtual member
functions, receiving different data, a total headache (almost
impossible).  It can be worked around by simply using slightly different
function names for each set of arguments... But why?  Why require someone
to shuffle routines names solely for differing arguments?  Isn't that the
entire purpose of overloaded functions?

Another common example of this problem is in deriving a template class
from a base class which implements default functionality for many of the
member functions.  Some member functions are overloaded in the template
class with functions that receive the template type, thus hiding the
inherited virtual functions of the same name!  (arg!)  This behavior seems
to undermine my attempts at designing code that's simple to use and
intuitive! ... I write classes for other programmers.  I'd perfer not to
force them to override functions they don't need, to do nothing but call
the inherited ones, just to keep them from getting hidden!

Also, while I'm at it, why can you only declare a friend function within a
class declaration?  What if the 'friendly' function is only used in one
translation unit (where the class is implemented), so it would be
preferable to make it 'static'?  Won't work...  Adding the prototype for
the function to the class declaration makes its prototype freely
available.  EVEN if it's within a protected or private section!  My
compiler allows me to add the 'static' to the prototype within the class
declaration, but what in the heck could that be impling?  The only
alternative is to make the function a static member, and put it in a
protected or private section... Seems like the long way around, to do
something very simple.  ... What if I don't want friends or derived
classes to be able to access it?  ...

Peeved,
 - Colen Garoutte-Carson, colen@phonet.com

P.S.  Please also email your response.  I do not regular this news group.
---
[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]