Hi,
   Does anyone know what the latest draft of the C++ Standard says about
the following usage:

        class X
        {
            public:
                X() : xp(0) {}
                operator X*() const {return xp;}
            protected:
                X* xp;
        };

        class Y : public X
        {
            public:
                Y() {}
                operator Y*() const {return (Y*) xp;}
        };

        void main()
        {
            X x;
            cout << (x == 0) << endl;
        }

The CenterLine 2.0.4 compiler does not repoort any ambiguity in the
(x == y) expression.

But the Lucid 3.1 compiler (using -XF) does:

____________________________________________________________
E, Two type conversion functions, X::operator "class X*" () and Y::operator "clas
s Y*" ()

                              v
22              cout << (y == 0) << endl;


Who is right?

--
Jerry Liebelson
jlieb@is.morgan.com
73477.2740@compuserve.com

>      Does anyone know what the latest draft of the C++ Standard says about
>   the following usage:
>
>           class X
>           {
>               public:
>                   X() : xp(0) {}
>                   operator X*() const {return xp;}
>               protected:
>                   X* xp;
>           };
>
>           class Y : public X
>           {
>               public:
>                   Y() {}
>                   operator Y*() const {return (Y*) xp;}
>           };
>
>           void main()
>           {
>               X x;
>               cout << (x == 0) << endl;
>           }
>


I think the above has a typo.  As it stands it is accepted
by Lucid's compiler.  The example on which Lucid and cfront
differ is:

        Y y ;
        cout << (y==0) << endl;

We consider this ambiguous because Y contains both an "operator X*"
and an "operator Y*".  It isn't completely clear whether using
"operator X*" also requires a derived->base conversion, but even if
you think it does, both conversion sequences involve user defined
conversions and so neither is "better" (at least the way I read the
current working paper, which has essentially the same overload
resolution algorithm as the ARM).

The C++ committee is considering a rewrite of the section that that
covers overload resolution.  Hopefully this rewrite will clarifying
some of the "dark corners" (such as that illustrated in the above
example).  If this rewrite declares the above is unambiguous
(presumably favoring the "operator Y*", which doesn't involve a
derived->base conversion) then Lucid will treat our current behavior
as a bug. However I personally hope the above example remains
ambiguous.


  -- Jerry Schwarz(jss@lucid.com)