On Jun 6, 2008, at 1:58 AM, Graham Cox wrote:
I agree, the compiler ought to be able to use the return type to
disambiguate two otherwise identically named methods (or warn of the
mismatch) - but it clearly doesn't.
My experimentation reveals, with the Xcode 2.5 tools, that the return
type of the first method in scope is used. That is, given two methods
in two different classes with the same names and different return
types the one that comes first in the compilation unit rules the
expected return type when sending the specified message to an id
variable.
Also, if code attempts to send a message to an id variable and that
message isn't in scope then warnings are issued and an assumption that
the message returns a type of id and takes varargs is used.
It seems almost certain that you had a 'position' method that returned
an integer type in scope somehow otherwise you either would have
gotten a warning or the code would have correctly expected a float.
Having said that, I can see why the code wouldn't work correctly but I
don't really know why it would result in memory corruption. Possibly
it's in the position method or in objc_msgSend, which was called
incorrectly instead of objc_msgSend_fpret.
On 6 Jun 2008, at 3:37 pm, Hamish Allan wrote:
On Fri, Jun 6, 2008 at 6:26 AM, Graham Cox <[EMAIL PROTECTED]>
wrote:
I guess the question is, given an object type 'id', which method
signature
will the compiler go with? Does the return type affect the method
signature?
(In C++ it doesn't for example), so two methods:
- (CGPoint) position;
- (float) position;
might well have identical signatures. The compiler doesn't have an
object
type to narrow it down, so which will it use - the first it finds
maybe.
I'd have thought that in the case:
// id anonymous
float f = [anonymous position];
the compiler ought to assume that the method being used is the one
returning a float, or if not at least warn about an implicit cast
from
CGPoint to float. Perhaps if it were -(int)position rather than
-(CGPoint)position, you might not expect a warning, but in that case
you would expect a cast, so it shouldn't break.
However, that does appear to be what is happening. In the absence of
any other explanation, I'd call it a compiler bug.
Hamish
_______________________________________________
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to [EMAIL PROTECTED]
