PATCH: Preserve ObjC type-casts in C++'s build_c_cast()
Ziemowit Laski
zlaski@apple.com
Fri Sep 10 04:00:00 GMT 2004
On 9 Sep 2004, at 19.07, Mark Mitchell wrote:
> Ziemowit Laski wrote:
>
>> This patch is analogous to one I installed in the C front-end a while
>> back,
>> after much discussion as I recall. :-) To recap: ObjC types
>> differing only
>> in protocol conformance (e.g., 'NSObject *' vs. 'NSObject <Foo> *')
>> will
>> appear equivalent to the C++ front-end, which is actually fine for
>> most
>> things, but not casts, since we want to retain the protocol
>> information.
>>
>> OK for mainline?
>
> Do you really want to do this if the types are actually the same? Or
> if one is a pointer-to-base and another is pointer-to-derived?
Yes. In ObjC, you need to preserve the type as specified, because that
may affect how the message dispatch is constructed and/or what
diagnostics are issued. By supplying a cast, e.g.,
Foo *foo;
...
[(Bar *)foo messageWithNumber:2 andNumber:3];
you are telling the compiler that it should assume that the message is
being sent to an object of type 'Bar', and therefore to search for a
"messageWithNumber:andNumber:" in Bar (and its superclasses, if
needed). It does not matter whether Foo and Bar are related; the two
could define the "messageWithNumber:andNumber:" method with different
argument types, for example.
I suppose we could optimize for the case when type == TREE_TYPE (expr),
but that's probably not worth the candle, since that would correspond
to a completely redundant cast that users are unlikely to have in their
code.
--Zem
--------------------------------------------------------------
Ziemowit Laski 1 Infinite Loop, MS 301-2K
Mac OS X Compiler Group Cupertino, CA USA 95014-2083
Apple Computer, Inc. +1.408.974.6229 Fax .5477
More information about the Gcc-patches
mailing list