Topic: private inh and casting
Author: jsa@edg.com (J. Stephen Adamczyk)
Date: 1995/04/19 Raw View
In article <HAYDENS.95Apr18162040@wayback.atc.ll.mit.edu> haydens@ll.mit.edu writes:
>class P {
> public:
> P() {}
>};
>
>class C : private P {
> public:
> C() {}
>
> operator P();
>};
>void fun(P);
>main()
>{
> C x;
>
>// fun(x); // won't compile
> fun(x.operator P()); // compiles just fine
>
> return 0;
>}
>
>SGI says that this new behavior isn't a bug, but correct according to
>(some version of) the ANSI draft. This is a real conversation stopper.
>
>Are they correct that according to the standard, private inheritance
>prevents a user defined cast from being called? That seems kind of odd
>to me. Could someone who has access to the draft please clear this up?
They are right, and the program is now wrong, but it has nothing to
do with private derivation. Recent versions of the Working Paper
say that conversion functions that convert a class to itself or to a
base class can be declared, but they don't get called for implicit
conversions, only when called explicitly by name (as in the second
call above). So the operator P() function is not considered as a
way to convert to the base class, and the built-in conversion cannot
be used either, because of the access problem.
Steve Adamczyk
Author: haydens@wayback.atc.ll.mit.edu (Hayden Schultz x3685 )
Date: 1995/04/18 Raw View
The commented out call to fun() doesn't compile (although the other call
does) with sgi's c++ compiler. Cfront compilers compile both calls to
fun() with no problem. Which is correct?
class P {
public:
P() {}
};
class C : private P {
public:
C() {}
operator P();
};
void fun(P);
main()
{
C x;
// fun(x); // won't compile
fun(x.operator P()); // compiles just fine
return 0;
}
SGI says that this new behavior isn't a bug, but correct according to
(some version of) the ANSI draft. This is a real conversation stopper.
Are they correct that according to the standard, private inheritance
prevents a user defined cast from being called? That seems kind of odd
to me. Could someone who has access to the draft please clear this up?
Thanks,
Hayden
--
Hayden Schultz
haydens@ll.mit.edu
MIT Lincoln Lab
Air Traffic Automation
244 Wood St.
Lexington, MA, 02173
(617) 981-3685