Re: Methods with the same name but different return types
Re: Methods with the same name but different return types
- Subject: Re: Methods with the same name but different return types
- From: Eyal Redler <email@hidden>
- Date: Fri, 03 Jun 2011 17:03:13 +0300
> You haven't told us what type myValue is so it's hard to tell if it
> matches the type in the array. If myValue is of type that myArray
> contains, the cast is unnecessary. If they don't match, the complier
> should be complaining. Now for the other method, it is part of the same
> class and has the same number of input parameters but only differs in the
> return type? Don't think that is possible as this should generate a
> compile error(what toolset are you using?). I bet you still have a problem
> somewhere else if the types match.
I'll try to explain the issue more clearly:
@class MyClass : NSObject
{ ... }
- (float)position;
@end
@class NSPositionalSpecifier : NSObject
{ ... }
- (int)position;
@end
NSArray* myArray=[[NSArray arrayWithObject:[[[MyClass alloc] initWithPosition:15.3] autorelease]] retain];
...
float myValue=[[myArray objectAtIndex:0] position]+0.01;
when running this, myValue gets a bad value.
Obviously the compiler teats the return value of position as being an int and not a float which is not good. The fix is obvious, I need to cast the result of [myArray objectAtIndex:0] to the correct class and the compiler will chose the correct method.
I didn't just that and the problem was gone but here is where the plot thickens, Fixing this issue also fixed the other (seemingly unrelated) problem of round() returning NaN.
What I was asking was this:
1. Is there a way to detect such cases? (Andreas mentioned GCC_WARN_STRICT_SELECTOR_MATCH which is quite close but producing a lot of false positives)
2. How could such an error lead to the side effects I've noticed?
Anther final comment to explain how nasty this was, normally if you have such an error you can detect it immediately after you write it since myValue getting a reticules value would surly show up when you test the code you just wrote.
The problem was that this ambiguity didn't exists when I originally wrote the code because I was using the 10.4 sdk and - (int)position was introduced in 10.5. The code was working fine for a few years until I recently switched to the 10.5 SDK.
Eyal
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Xcode-users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden