🚀 go-pugleaf

Hi everybody,

I don't know what happened to my previous article on this topic so I've 
rewritten it and now I'll try it again.

In the present standard as well as in the April draft, there exists one 
rule which I don't like at all. Basically, the concept is that if several 
overloaded functions are defined in a class A and one of these functions 
is redefined in a derived class B this function hides all functions 
inherited from A that have the same name:

class A
{
public:
 void	foo();
 void	foo( int );
};

class B : public A
{
public:
 void	foo();	// void foo(int) is hidden; use A::foo(int)
};

I don't understand why this rule has been invented. It seriously affects 
the concepts of reusability and encapsulation. In fact, imagine A is 
defined in a class library and B is a class a user created which requires 
foo(void) to be reimplemented but still wants to use foo(int). Of course 
one can use a qualifier to access the hidden function; however, you have 
to know in which class the function has been declared then. This is not 
difficult in the above example; in a class library with a deep inheritance 
tree this is more than inconvenient. Things get even worse when dealing 
with virtual functions. Virtual functions are an excellent way to define a 
behaviour which might ( but must not ) be altered in more special classes 
( this is not all what virtual functions can do but it is an essential 
part ). A great advantage of this mechanism is that you do not have to 
know exactly in which class the behaviour is defined: you simply use it or 
alter it. Now consider the following example:

class A
{
public:
 virtual	void foo();
};

class B : public A
{
public:
 virtual	void foo( int );
};

class C1 : public B
{
public:
 virtual	void foo();
};

class C2 : public B
{
public:
 virtual	void foo();
};

int 

I don't think it is too far-fetched.
A solution could be that the developer redeclares all overloaded functions 
in every class where at least one of them has to be redeclared. Why should 
he have to do so? If you create a derived class you expect it to have the 
entire functionality of the base class; usually you simply want to extend 
this functionality or somehow specialise it but you do not expect that a 
member function cannot be called directly just because you redeclared 
another member function. This is simply not OOP. 
In fact, the April draft is contradictory here. It says:

  Members of  a  class  are  data  members,  member functions, nested
  types, and member constants (9.2.1),

and then later:

  Unless  redefined  in  the derived class, members of a base class can be     
  referred to  in  expressions  as  if  they were members of the derived   
  class (10.1).

Now, if I redefine an overloaded function I certainly do redefine a 
member. However, it is only one member I redefine so why am I not able to 
access other members I have not redefined? What I really miss in the draft 
is a definition like: "Functions are uniquely identified by their name and 
their parameter declaration" ( it's not perfect, I know ). To me, this 
would make the concept of the language clearer and the language itself 
easier to use.

Bye

Roman
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your 
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu 
]