468,765 Members | 801 Online
Bytes | Developer Community
New Post

Home Posts Topics Members FAQ

Post your question to a community of 468,765 developers. It's quick & easy.

Is this ambiguous?

Consider the following code, with the interesting lines numbered in
comments:

class A
{
public :

bool f(int level = 1) // line 5
{ return true ; }

void f(bool val, int level = 1)
{}

} ;

class B
{
private :
A *a ;
public :
bool f(int level = 1) // line 18
{ return a->f(level) ; } // line 19

void f(bool val, int level = 1)
{ a->f(val, level) ; }
} ;
This compiles fine for me (gcc 3.4.4). However, if I make the functions
on line 5 and line 18 const, then my compiler says the function call on
line 19 is ambiguous. It makes sense to me why it would be ambiguous
(level is convertible to bool, and so it might could match f(bool, int)
since the int parameter has a default value). However, what I don't
understand is why it is NOT ambiguous without the const. Any insight?

-Alan
Jul 23 '05 #1
1 2270
* Alan Johnson:
Consider the following code, with the interesting lines numbered in
comments:

class A
{
public :

bool f(int level = 1) // line 5
{ return true ; }

void f(bool val, int level = 1)
{}

} ;

class B
{
private :
A *a ;
public :
bool f(int level = 1) // line 18
{ return a->f(level) ; } // line 19

void f(bool val, int level = 1)
{ a->f(val, level) ; }
} ;
This compiles fine for me (gcc 3.4.4). However, if I make the functions
on line 5 and line 18 const,
The one on line 18 doesn't matter.
then my compiler says the function call on
line 19 is ambiguous. It makes sense to me why it would be ambiguous
(level is convertible to bool, and so it might could match f(bool, int)
since the int parameter has a default value). However, what I don't
understand is why it is NOT ambiguous without the const. Any insight?


First, be clear that result types are not considered in overload
resolution, and that making the function on line 18 const does not
make the object pointed to by 'a' const.

Without the const on line 5 the compiler has a choice between no
conversion, and conversion of the argument to bool. The no-conversion
is clearly better. Hence the first function is selected.

With the const on line 5 either 'a*' must be converted to
'a const*', or int must be converted to bool. I don't recall the
exact rules, but at least there are now two possible conversions. It
surprises me that the to-const conversion should weight in as much
as a possible value representation change (and a lossy one, at that!),
but then, the C++ rules are evolved beasts with lots of non-optimum
and counter-intuitive consequences.

--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?
Jul 23 '05 #2

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

16 posts views Thread by REH | last post: by
9 posts views Thread by xuatla | last post: by
1 post views Thread by Alex Zhitlenok | last post: by
3 posts views Thread by Arpan | last post: by
1 post views Thread by rn5a | last post: by
8 posts views Thread by xtrigger303 | last post: by
12 posts views Thread by Nathan Sokalski | last post: by
3 posts views Thread by i3x171um | last post: by
1 post views Thread by CARIGAR | last post: by
reply views Thread by Marin | last post: by
By using this site, you agree to our Privacy Policy and Terms of Use.