Marcello wrote:
So at the end it seems that the standard C++ is treating a difference betweenconst and non-const at the same level as a difference between types completelyunrelated. This, even when the the const specifier is just there to tell thatwhat is specified as const will not be changed by the function using that instance
const isn't just there to portray information to the compiler, it actually changes the type. So char* and const char* are as different (to the compiler) as char* and float. The difference between the two examples is that the compiler has rules for implicity converting between the first pair, but not the second. So const on a function definition doesn't just tell the compiler that the function doesn't modify any of the class members, it also changes the way the compiler handles ambiguity resolution, as you've found out - because the type of the function is different. Incidentally, this is also why you can have two identical function signatures that differ only in their "constness" - they are different types. As for your first point, neither of the functions is an exact match, but both of them can be satisfied by implicit conversion rules, so the call is ambiguous. In this case, the first parameter is a MyString&, which matches the second function but not the first, and the second parameter is a MyString::size_type* which matches the first function, but not the second. However, MyString& can be implicitly converted to const MyString&, and also MyString::size_type* can be implicitly converted to const bool&, and the compiler really has no way of knowing which you intended. It has no choice but to flag the ambiguity. Casting either parameter explicitly should remove the ambiguity. As you have hinted, the VS2005 compiler is much more strict than previous compilers, but it is behaving according to the standard.
Ryan
"Punctuality is only a virtue for those who aren't smart enough to think of good excuses for being late" John Nichol "Point Of Impact"
