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

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
>
> 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
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask

On Dec 6, 8:52 pm, Darko <darko.maksimo...@gmail.com> 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
>
> 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.

On Dec 6, 4:56 pm, "Victor Bazarov" <v.Abaza...@comAcast.net> wrote:
> 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
>
> > 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
> --
> Please remove capital 'A's when replying by e-mail
> I do not respond to top-posted replies, please don't ask

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 ed me with "hiding", though,
which I never knew occurred in the first place, so thanks and
have a good day!

Darko

Darko wrote:
> On Dec 6, 4:56 pm, "Victor Bazarov" <v.Abaza...@comAcast.net> wrote:
>> 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 ed me with "hiding", though,
> which I never knew occurred in the first place, so thanks and
> have a good day!

You too!

V
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask

On Dec 6, 6:56 pm, "Victor Bazarov" <v.Abaza...@comAcast.net> wrote:
> Darko wrote:
> > On Dec 6, 4:56 pm, "Victor Bazarov" <v.Abaza...@comAcast.net> wrote:
> >> 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 ed me with "hiding", though,
> > which I never knew occurred in the first place, so thanks and
> > have a good day!
>
> You too!
>
> V
> --
> Please remove capital 'A's when replying by e-mail
> I do not respond to top-posted replies, please don't ask

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

Darko wrote:
>>>Thus, I found your patronizing tone
>>>offensive and senseless.

Victor Bazarov wrote:
>>I find ignorance offensive, so?

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

On 7 Dec., 08:41, Stuart Redmann <DerTop...@web.de> wrote:
> Darko wrote:
> >>>Thus, I found your patronizing tone
> >>>offensive and senseless.
> Victor Bazarov wrote:
> >>I find ignorance offensive, so?
>
> 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

On 2007-12-07 03:05:56 -0500, peter koch <peter.koch.larsen@gmail.com> said:

> On 7 Dec., 08:41, Stuart Redmann <DerTop...@web.de> wrote:
>> Darko wrote:
>>>>> Thus, I found your patronizing tone
>>>>> offensive and senseless.
>> Victor Bazarov wrote:
>>>> I find ignorance offensive, so?
>>
>> 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?
>

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

Thanks.

--

-kira

Kira Yamato wrote:
> [..] 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
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask

On Dec 6, 4:56 pm, "Victor Bazarov" <v.Abaza...@comAcast.net> wrote:
> 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%).

> > 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.

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 (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34

On Dec 7, 8:41 am, Stuart Redmann <DerTop...@web.de> wrote:
> Darko wrote:
> >>>Thus, I found your patronizing tone
> >>>offensive and senseless.
> Victor Bazarov wrote:
> >>I find ignorance offensive, so?

> 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.

--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34

On 2007-12-07 09:27:05 -0500, "Victor Bazarov" <v.Abazarov@comAcast.net> said:

> Kira Yamato wrote:
>> [..] 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

On 2007-12-07 11:55:19 -0500, Kira Yamato <kirakun@earthlink.net> said:

> On 2007-12-07 09:27:05 -0500, "Victor Bazarov" <v.Abazarov@comAcast.net> said:
>
>> Kira Yamato wrote:
>>> [..] 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?

--

-kira

Kira Yamato wrote:
> [..]
> 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
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask

On 2007-12-07 12:02:44 -0500, Kira Yamato <kirakun@earthlink.net> said:

>
> 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.

--
Pete
Roundhouse Consulting, Ltd. (www.versatilecoding.com) Author of "The
Standard C++ Library Extensions: a Tutorial and Reference
(www.petebecker.com/tr1book)

On 2007-12-07 12:23:17 -0500, "Victor Bazarov" <v.Abazarov@comAcast.net> said:

> Kira Yamato wrote:
>> [..]
>> 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.

--

-kira

Kira Yamato wrote:
> On 2007-12-07 12:23:17 -0500, "Victor Bazarov"
> <v.Abazarov@comAcast.net> said:
>> Kira Yamato wrote:
>>> [..]
>>> 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
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask