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