In article <4ikob2$bs1@engnews1.Eng.Sun.COM>, clamage@Eng.Sun.COM (Steve Clamage) writes:
>I think the rules in the draft make sense in this case, if only because it
>is bound to be confusing to have a pair of overloaded functions like these.
>I don't think it is obvious that either function is the one intended, so
>the ambiguity ensures you specify precisely what you intend. That is,
>you give the functions different names, or incompatible parameter lists,
>or write the call more explicitly, for example:
> b.f(int(c))
> ((A&)b).f(c)
>If you have to write calls like this, I would seriously consider whether
>it makes sense to overload the functions.

I agree that using this kind of overloading is a bad idea (BTW, this is
not a real life example, just a test for my compiler).

However, the fact that the above call is ambiguous is not logical, IMHO,
because it wouldn't be ambiguous if 'b' had type 'A' instead of 'B'.
Deriving a class should not turn an unambiguous call into an ambiguous
one. A derived class is expected to have the same behaviour as its base.

Why not have the standard say something like: the implicit object
parameter for a static member function of class A has type
'const volatile A&' ?

___________________________________________________

Emmanuel Lesueur  -   elesueur@ens-lyon.fr




[ 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
]

In article 4i@cri.ens-lyon.fr, elesueur@ens-lyon.fr (Emmanuel Lesueur) writes:
>
>Oops... You're right, of course. I swapped the function parameters.
>What about:
>
>> class A {
>> public:
>>  void f(char);  #1
>>  static void f(int); #2
>> };
>
>> class B : public A {
>> };
>
>> void foo(B& b,char c) {
>>  b.f(c);
>> }
>
>Is this ambiguous ? As I understand it, the draft paper says yes.
>(gcc says no.)

By my reading of the draft, #1 requires a base-class conversion on the
first (implicit) argument and has an exact match on the second (char)
argument. Function #2 has an exact match on the fictional first argument,
and requires a promotion on the second (int) parameter. #2 is preferred
on the first argument and #1 is preferred on the second argument. Thus,
I agree that the call is ambiguous according to the draft standard.

The detailed rules for overloading have undergone changes over time, and
I believe under earlier sets of rules f(char) could be unambiguously
selected.

I think the rules in the draft make sense in this case, if only because it
is bound to be confusing to have a pair of overloaded functions like these.
I don't think it is obvious that either function is the one intended, so
the ambiguity ensures you specify precisely what you intend. That is,
you give the functions different names, or incompatible parameter lists,
or write the call more explicitly, for example:
 b.f(int(c))
 ((A&)b).f(c)
If you have to write calls like this, I would seriously consider whether
it makes sense to overload the functions.
---
Steve Clamage, stephen.clamage@eng.sun.com
---
[ 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
]