🚀 go-pugleaf

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
]