This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: PATCH: Preserve ObjC type-casts in C++'s build_c_cast()



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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]