Hello folks, a month ago I posted a question  about const overloading
and ambiguity, but did not receive ANY answer (except one email). Does
really nobody use constructs like the following?

   struct A {
     int &f();
     int f() const;  // const overloading
     };


When I define

   struct B : protected  A {
     void g() { f()=3; }  // not ambiguous
     };

   struct C : public B {
     void h() { f()=3; }  // ambiguous
     };

the call of A::f in C::h is ambiguous with BC 4.5.

The same call of f is not ambiguous in B::g and it is also not in C if
B were derived public instead of protected.

Is this behaviour correct? (Maybe we have *really* a compiler bug
here). What about other compilers?

If the behaviour *is* correct,  what is the rationale? (I can't think
of any).

Thanks, Martin.


-----------------------------------
Signatures are a waste of bandwidth
-----------------------------------
---
[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

In article <4o3t8s$mbc@hil-news-svc-2.compuserve.com>
100754.2730@compuserve.com (Martin Aupperle) writes:
>   struct A {
>     int &f();
>     int f() const;  // const overloading
>     };
>
>
>When I define
>
>   struct B : protected  A {
>     void g() { f()=3; }  // not ambiguous
>     };
>
>   struct C : public B {
>     void h() { f()=3; }  // ambiguous
>     };
>
>the call of A::f in C::h is ambiguous with BC 4.5.
>
>The same call of f is not ambiguous in B::g and it is also not in C if
>B were derived public instead of protected.
>
>Is this behaviour correct? (Maybe we have *really* a compiler bug
>here). What about other compilers?

This is a compiler bug.  The call is not ambiguous.  One useful concept
to apply to analysis of problems like this: access affects the validity of
a program, not its meaning.  Things that are inaccessible are not
invisible.  So if a program is valid, it will still be valid and mean the
same thing if you change everything in it to public.  (There are some
exceedingly obscure exceptions to this rule, for cases that involve
some form of access checking at runtime, e.g., throw derived/catch private
base.)  A difference of interpretation due solely to a change in access
specifications indicates a compiler bug.

Steve Adamczyk
---
[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

100754.2730@compuserve.com (Martin Aupperle) writes:

>Does really nobody use constructs like the following?

>   struct A {
>     int &f();
>     int f() const;  // const overloading
>     };

Yes. It is a common way to implement operator[], for example.
When invoked on a const object, the const version of f is called.
When invoked on a non-const object, the non-const version of f is called.


>When I define

>   struct B : protected  A {
>     void g() { f()=3; }  // not ambiguous
>     };

>   struct C : public B {
>     void h() { f()=3; }  // ambiguous
>     };

>the call of A::f in C::h is ambiguous with BC 4.5.

>The same call of f is not ambiguous in B::g and it is also not in C if
>B were derived public instead of protected.

If that is so, it is a compiler bug. Overloaded resolution is
performed without regard to accessibility. Functions are ambiguous
or not ambiguous without regard to protection. If one function is
unambiguously selected but is not accessible, that is an accesibility
error, not an ambiguity.

In this case, there is no problem with accessibility.

--
Steve Clamage, stephen.clamage@eng.sun.com
---
[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]