Am I the only one mad here?

[Darko]

The following code doesn't work:

01: class A {
02: public:
03: bool f( int x )
04: {
05: return x>1;
06: }
07: };
08:
09: class B: public A {
10: public:
11: bool f()
12: {
13: return f(3) ;
14: }
15: };
16:
17: int main()
18: {}

Compiler reports the following error:
g++ proba.cpp -o proba
proba.cpp: In member function `bool B::f()':
proba.cpp:13: error: no matching function for call to `B::f(int)'
proba.cpp:12: note: candidates are: bool B::f()
make: *** [proba] Error 1

Since I suppose you are going to propose putting A::f(3), I can tell
you I've already tried to do that and it works. But:
* Why would I have to do that!? The methods are perfectly distinct
having different arguments.
* If I do that, then the following code still doesnt work:

01: class A {
02: public:
03: bool f( int x )
04: {
05: return x>1;
06: }
07: };
08:
09: class B: public A {
10: public:
11: bool f()
12: {
13: return A::f(3) ;
14: }
15: };
16:
17: int main()
18: {
19: B b;
20: b.f( 4 );
21: }
giving the following error:

proba.cpp: In function `int main()':
proba.cpp:20: error: no matching function for call to `B::f(int)'
proba.cpp:12: note: candidates are: bool B::f()
make: *** [proba] Error 1

Now what do you think about that? Personally, it broke my C++
confidence.

Regards,

Darko

 

[Victor Bazarov]

The following code doesn't work:

01: class A {
02: public:
03: bool f( int x )
04: {
05: return x>1;
06: }
07: };
08:
09: class B: public A {
10: public:
11: bool f()
12: {
13: return f(3) ;
14: }
15: };
16:
17: int main()
18: {}

Compiler reports the following error:
g++ proba.cpp -o proba
proba.cpp: In member function `bool B::f()':
proba.cpp:13: error: no matching function for call to `B::f(int)'
proba.cpp:12: note: candidates are: bool B::f()
make: *** [proba] Error 1

Since I suppose you are going to propose putting A::f(3), I can tell
you I've already tried to do that and it works. But:
* Why would I have to do that!? The methods are perfectly distinct
having different arguments.

Read about "overloading" versus "hiding".

* If I do that, then the following code still doesnt work:

01: class A {
02: public:
03: bool f( int x )
04: {
05: return x>1;
06: }
07: };
08:
09: class B: public A {
10: public:
11: bool f()
12: {
13: return A::f(3) ;
14: }
15: };
16:
17: int main()
18: {
19: B b;
20: b.f( 4 );
21: }
giving the following error:

proba.cpp: In function `int main()':
proba.cpp:20: error: no matching function for call to `B::f(int)'
proba.cpp:12: note: candidates are: bool B::f()
make: *** [proba] Error 1

Now what do you think about that?

Nothing in particular. It's the error in your code. You can fix
it by doing

b.A::f(4);

Personally, it broke my C++
confidence.

Was there confidence to begin with?

As soon as you understand the difference between "overloading",
"hiding", and "overriding", you'll know what to do. You also might
want to learn about "name lookup", although it's not really a simple
topic.

V

 

[Abhishek Padmanabh]

The following code doesn't work:

01: class A {
02: public:
03: bool f( int x )
04: {
05: return x>1;
06: }
07: };
08:
09: class B: public A {
10: public:
11: bool f()
12: {
13: return f(3) ;
14: }
15: };
16:
17: int main()
18: {}

Compiler reports the following error:
g++ proba.cpp -o proba
proba.cpp: In member function `bool B::f()':
proba.cpp:13: error: no matching function for call to `B::f(int)'
proba.cpp:12: note: candidates are: bool B::f()
make: *** [proba] Error 1

Since I suppose you are going to propose putting A::f(3), I can tell
you I've already tried to do that and it works. But:
* Why would I have to do that!? The methods are perfectly distinct
having different arguments.
* If I do that, then the following code still doesnt work:

01: class A {
02: public:
03: bool f( int x )
04: {
05: return x>1;
06: }
07: };
08:
09: class B: public A {
10: public:
11: bool f()
12: {
13: return A::f(3) ;
14: }
15: };
16:
17: int main()
18: {
19: B b;
20: b.f( 4 );
21: }
giving the following error:

proba.cpp: In function `int main()':
proba.cpp:20: error: no matching function for call to `B::f(int)'
proba.cpp:12: note: candidates are: bool B::f()
make: *** [proba] Error 1

Now what do you think about that? Personally, it broke my C++
confidence.

As a resolution, you may want to put using A::f; in class B, the
derived class. This brings the base class overload in the set of
overloads that b.f() will look for to find a match. And it will find
it.

 

[Darko]

The following code doesn't work:

01: class A {
02: public:
03: bool f( int x )
04: {
05: return x>1;
06: }
07: };
08:
09: class B: public A {
10: public:
11: bool f()
12: {
13: return f(3) ;
14: }
15: };
16:
17: int main()
18: {}

Compiler reports the following error:
g++ proba.cpp -o proba
proba.cpp: In member function `bool B::f()':
proba.cpp:13: error: no matching function for call to `B::f(int)'
proba.cpp:12: note: candidates are: bool B::f()
make: *** [proba] Error 1

Since I suppose you are going to propose putting A::f(3), I can tell
you I've already tried to do that and it works. But:
* Why would I have to do that!? The methods are perfectly distinct
having different arguments.

Read about "overloading" versus "hiding".

* If I do that, then the following code still doesnt work:

01: class A {
02: public:
03: bool f( int x )
04: {
05: return x>1;
06: }
07: };
08:
09: class B: public A {
10: public:
11: bool f()
12: {
13: return A::f(3) ;
14: }
15: };
16:
17: int main()
18: {
19: B b;
20: b.f( 4 );
21: }
giving the following error:

proba.cpp: In function `int main()':
proba.cpp:20: error: no matching function for call to `B::f(int)'
proba.cpp:12: note: candidates are: bool B::f()
make: *** [proba] Error 1

Now what do you think about that?

Nothing in particular. It's the error in your code. You can fix
it by doing

b.A::f(4);

Personally, it broke my C++
confidence.

Was there confidence to begin with?

As soon as you understand the difference between "overloading",
"hiding", and "overriding", you'll know what to do. You also might
want to learn about "name lookup", although it's not really a simple
topic.

V

Thanks, the "hiding" term saved me. I looked it up on the Internet,
and guess what: you don't have to use that ugly construction:
b.A::f(4);
but can say something like this:
using A::f;
in the class B, and then everything works fine.

I must also mention that overriding doesn't have
anything to do with this, since no class method is overridden here,
and if overloading worked well, then no issue would exist.
As you may notice, f() and f(int) overload each other perfectly,
because they have a different number of arguments, although argument
types would suffice, too; so, based on my previous knowledge
no problem should occurr. Thus, I found your patronizing tone
offensive and senseless. You have helped me with "hiding", though,
which I never knew occurred in the first place, so thanks and
have a good day!

Darko

 

[Victor Bazarov]

The following code doesn't work:

01: class A {
02: public:
03: bool f( int x )
04: {
05: return x>1;
06: }
07: };
08:
09: class B: public A {
10: public:
11: bool f()
12: {
13: return f(3) ;
14: }
15: };
16:
17: int main()
18: {}

Compiler reports the following error:
g++ proba.cpp -o proba
proba.cpp: In member function `bool B::f()':
proba.cpp:13: error: no matching function for call to `B::f(int)'
proba.cpp:12: note: candidates are: bool B::f()
make: *** [proba] Error 1

[..] if overloading worked well, then no issue would exist.

Overloading works well. You may not understand how it works, but
that is no reason to attack the feature of the language or the
compiler. To answer the question in your subj line, yes, you are,
if you insist on calling ignorance "madness".

As you may notice, f() and f(int) overload each other perfectly,

Only if they are in the same scope.

because they have a different number of arguments, although argument
types would suffice, too; so, based on my previous knowledge
no problem should occurr.

Your previous knowledge wasn't enough, apparently. But are you
sure your current knowledge is sufficient?

Thus, I found your patronizing tone
offensive and senseless.

I find ignorance offensive, so?

You have helped me with "hiding", though,
which I never knew occurred in the first place, so thanks and
have a good day!

You too!

V

 

[Darko]

Darko wrote:
The following code doesn't work:
01: class A {
02: public:
03: bool f( int x )
04: {
05: return x>1;
06: }
07: };
08:
09: class B: public A {
10: public:
11: bool f()
12: {
13: return f(3) ;
14: }
15: };
16:
17: int main()
18: {}
Compiler reports the following error:
g++ proba.cpp -o proba
proba.cpp: In member function `bool B::f()':
proba.cpp:13: error: no matching function for call to `B::f(int)'
proba.cpp:12: note: candidates are: bool B::f()
make: *** [proba] Error 1

[..] if overloading worked well, then no issue would exist.

Overloading works well. You may not understand how it works, but
that is no reason to attack the feature of the language or the
compiler. To answer the question in your subj line, yes, you are,
if you insist on calling ignorance "madness".

As you may notice, f() and f(int) overload each other perfectly,

Only if they are in the same scope.

because they have a different number of arguments, although argument
types would suffice, too; so, based on my previous knowledge
no problem should occurr.

Your previous knowledge wasn't enough, apparently. But are you
sure your current knowledge is sufficient?

Thus, I found your patronizing tone
offensive and senseless.

I find ignorance offensive, so?

You have helped me with "hiding", though,
which I never knew occurred in the first place, so thanks and
have a good day!

You too!

V

If you find ignorance offensive, then I suggest you not come to this
group,
any group actually, cause you'll get offended every now and then ;-)

Cheers

 

[Stuart Redmann]

Cut it out, you two, throwing around with accusations won't do either of you any
good.

Personally, I find the concept of function hiding rather useless (and there is
quite a number of people who will agree with me) and prone to confusion. Thus I
can understand OP's consternation when he stumbled over this particular
"feature" of the C++ language. To avoid discussion like this in the future it
would be the best if the concept of "function hiding" would disappear from the
C++ language.

Regards,
Stuart

 

[peter koch]

Cut it out, you two, throwing around with accusations won't do either of you any
good.

I agree ;-)

Personally, I find the concept of function hiding rather useless (and there is
quite a number of people who will agree with me) and prone to confusion. Thus I
can understand OP's consternation when he stumbled over this particular
"feature" of the C++ language. To avoid discussion like this in the future it
would be the best if the concept of "function hiding" would disappear from the
C++ language.

I can understand your point, but there are situation where function
hiding is justified and not having function hiding could result in a
nasty surprise difficult to decipher. Example:

struct base
{
operator=(base const&); // might be implicit
.....
};

struct derived: base
{
operator=(derived const&) // might be implicit
.....
};


.....
derived d;
base b;

d = b; // will compile if operator=(base const&) is not hidden.

So I believe that - how confusing it might seem - the rule was well
thought out. Perhaps this is a place where we should look for better
errormessages?


/Peter

 

[Kira Yamato]

I agree ;-)

I can understand your point, but there are situation where function
hiding is justified and not having function hiding could result in a
nasty surprise difficult to decipher. Example:

struct base
{
operator=(base const&); // might be implicit
....
};

struct derived: base
{
operator=(derived const&) // might be implicit
....
};


....
derived d;
base b;

d = b; // will compile if operator=(base const&) is not hidden.

So I believe that - how confusing it might seem - the rule was well
thought out. Perhaps this is a place where we should look for better
errormessages?

Nice example! I was looking for a convincing reason why overriding was
introduced in C++.

Thanks.

 

[Victor Bazarov]

[..] I was looking for a convincing reason why overriding
was introduced in C++.

Overriding was introduced as part of implementation of run-time
polymorphism in the language. Without overriding it would be
useless to declare functions virtual. If they don't override,
how would the derived class provide its own behaviour for the
declared virtual function in the class it inherits?

Or did you mean you were looking for a convincing reason why
_name hiding_ was introduced in C++?

V

 

[James Kanze]

Darko wrote:

[Classical problem concerning function hiding...]

Nothing in particular. It's the error in your code. You can
fix it by doing

b.A::f(4);

More likely, if the intent is to be able to call A::f with an
object of type B, he should add "using A::f;" to B. (I'm not
sure of the syntax. I've never wanted to do this.)

Note that this is often symtomatic of a bad design. In my
experience, about 90% of my derivation is directly from an
"interface", and once the object is constructed, the client
never uses anything but the interface. But there are certainly
exceptions (i.e. 90% isn't 100%).

Was there confidence to begin with?

As soon as you understand the difference between
"overloading", "hiding", and "overriding", you'll know what to
do. You also might want to learn about "name lookup",
although it's not really a simple topic.

Nothing in C++ is as simple as it could be. In many cases, it's
because of the C heritage. But in a few cases, like this one,
the "unexpected" behavior turns out to really be much more
useful in larger projects than the "intuitive" behavior would
be.

 

[James Kanze]

Cut it out, you two, throwing around with accusations won't do
either of you any good.

Personally, I find the concept of function hiding rather
useless (and there is quite a number of people who will agree
with me) and prone to confusion.

Could it be that you've never worked on a large, well designed
project. It's an essential safety feature, one I'd not like to
see lost.

Thus I can understand OP's consternation when he stumbled over
this particular "feature" of the C++ language. To avoid
discussion like this in the future it would be the best if the
concept of "function hiding" would disappear from the C++
language.

We could dumb down the language, and eliminate safety features
which cause confusion. Java went this route; the language is
probably easier to learn, but I certainly wouldn't want to use
it on a project of any size.

 

[Kira Yamato]

[..] I was looking for a convincing reason why overriding
was introduced in C++.

Overriding was introduced as part of implementation of run-time
polymorphism in the language. Without overriding it would be
useless to declare functions virtual. If they don't override,
how would the derived class provide its own behaviour for the
declared virtual function in the class it inherits?

Or did you mean you were looking for a convincing reason why
_name hiding_ was introduced in C++?

Yes, I meant hiding. I was always under the same impression as the OP
that hiding surprises the programmers. Afterall, [public] inheritance
means derived classes should see "everything" [ok, non-private stuff]
from base class. However, hiding took away this for overloaded
functions.

And I couldn't find any FAQ online which had given a good explanation
why. That is until now...

 

[Kira Yamato]

[..] I was looking for a convincing reason why overriding
was introduced in C++.

Overriding was introduced as part of implementation of run-time
polymorphism in the language. Without overriding it would be
useless to declare functions virtual. If they don't override,
how would the derived class provide its own behaviour for the
declared virtual function in the class it inherits?

Or did you mean you were looking for a convincing reason why
_name hiding_ was introduced in C++?

Yes, I meant hiding. I was always under the same impression as the OP
that hiding surprises the programmers. Afterall, [public] inheritance
means derived classes should see "everything" [ok, non-private stuff]
from base class. However, hiding took away this for overloaded
functions.

And I couldn't find any FAQ online which had given a good explanation
why. That is until now...

Hmm... This raises a possibly off-topic question. I believe java does
not hide overloaded functions like C++. Does this mean java suffer
from some problems that C++ has avoided by introducing hiding?

For example, does this mean it is possible to clone a java object only
partially?

 

[Victor Bazarov]

[..]
Hmm... This raises a possibly off-topic question. I believe java
does not hide overloaded functions like C++. Does this mean java
suffer from some problems that C++ has avoided by introducing hiding?

In Java all functions are virtual. Does that answer your question?

For example, does this mean it is possible to clone a java object only
partially?

Ask in a Java newsgroup.

V

 

[Pete Becker]

Hmm... This raises a possibly off-topic question. I believe java does
not hide overloaded functions like C++. Does this mean java suffer
from some problems that C++ has avoided by introducing hiding?

Yes. A large part of Java's appeal to beginning programmers is that its
library was designed by beginners, and has lots of beginner's mistakes.

 

[Kira Yamato]

[..]
Hmm... This raises a possibly off-topic question. I believe java
does not hide overloaded functions like C++. Does this mean java
suffer from some problems that C++ has avoided by introducing hiding?

In Java all functions are virtual. Does that answer your question?

Not really. In C++, you hide virtual base class methods too.

 

[Victor Bazarov]

[..]
Hmm... This raises a possibly off-topic question. I believe java
does not hide overloaded functions like C++. Does this mean java
suffer from some problems that C++ has avoided by introducing
hiding?

In Java all functions are virtual. Does that answer your question?

Not really. In C++, you hide virtual base class methods too.

Then I don't know the answer. In all my Java forays I didn't write
a single derived class that would hide the base class' methods. Come
to think of it, I don't usually write C++ classes that way either.

Of course the operator= example mentioned in this thread some time
ago is the only example of something that always hides the base's
implementation of it without any effort from the programmer. So,
it is an exception (i.e. I don't intentionally hide op= from base,
it just happens to be hidden even if I don't write my own op=).

V