Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!wuarchive!uunet!bywater!arnor!watson!blinn.watson.ibm.com!mittle From: mittle@blinn.watson.ibm.com (Josh Mittleman) Newsgroups: comp.lang.c++ Subject: Re: Pointers to sibling classes in conditional expressions Message-ID: <1991Apr30.170506.15087@watson.ibm.com> Date: 30 Apr 91 17:05:06 GMT References: <1991Apr26.152511.14662@watson.ibm.com> <1991Apr29.173219.29532@alias.com> Sender: @watson.ibm.com Distribution: comp Organization: IBM T. J. Watson Research Lines: 33 >"If both the second and the third expressions are of arithmetic type, the >usual arithmetic conversions are performed to bring them to a common type. >Otherwise, if both the second and the third expressions are either a >pointer or a constant expression that evaluates to 0, pointer conversions ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >are performed to bring them to a common type. Otherwise, if both the >second and the third expressions are either references, reference +++++++++ >conversions are performed to bring them to a common type. Otherwise if ++++++++++++++++++++++++++++++++++++++++++++++++++++++++ >both the second and the third expressions are void, the common type is >void. Otherwise if both the second and the third expressions are the same >class T, the common type is T. Otherwise the expression is illegal." In article <1991Apr29.173219.29532@alias.com>, rae@alias.com (Reid Ellis) writes: > I think the problem is in the "^^" marked phrase above. On first > reading, it would seem to indicate "(a pointer that evaluates to 0) or > (a constant expression that evaluates to 0)". But after some thought, > and especially after reading the section marked with "+" above, it > would seem that that phrase should be read as "(a pointer) or (a > constant expression that evaluates to 0)". Good point. It has also been pointed out that the problem of converting two pointers to a common type is non-trivial, and may be indeterminate if the two classes have two common base classes. This last case *must* generate an error, and it is not obvious how to design a conversion scheme that could distinguish this case from other, determinate cases. =========================================================================== Josh Mittleman (mittle@watson.ibm.com or joshua@paul.rutgers.edu) J2-C28 T.J. Watson Research Center, PO Box 704, Yorktown Heights, NY 10598