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: Andreas Grosam <email@hidden>
- Date: Fri, 03 Jun 2011 10:13:13 +0200
On Jun 2, 2011, at 3:38 PM, Eyal Redler wrote:
> Hi,
>
> One of my classes declares the following method:
>
> - (float)position;
>
> Sometimes I store objects of this class inside an NSArray and then access this method, for example:
>
> #define kMyConstant (float)0.1;
> myValue=[[myArray objectAtIndex:i] position]+kMyConstant;
>
> Recently I've discovered that sometimes I'm getting very strange values for "myValue" even though the actual object contains a normal number which is something I've checked by stepping in the code with the debugger.
>
> After some research I found that there is another method with the same name but with a different return type
>
> NSPositionalSpecifier
> ...
> - (NSInsertionPosition)position;
>
> Obviously the compiler is treating the return value from "position" as an integer while it is actually a float, leading to bogus values. I've changed the code by explicitly casting the array access to the class and all was well:
>
> myValue=[(MYClass*)[myArray objectAtIndex:i] position]+kMyConstant;
>
> The interesting thing is that I found that some other unexplainable problems that I was getting (like round() returning NaN for a perfectly legal number seem to have disappeared.
>
> This leads me to the following two questions
> 1. Is there a way to detect ambiguous cases like this and get a warning. Maybe there is a third party tool or a methodology for this. I suspect that there are other such problems lurking in my code...
There is a warning flag in Xcode "Strict Selector Matching" ( [GCC_WARN_STRICT_SELECTOR_MATCH, -Wstrict-selector-match] in clang, gcc) which is disabled by default. If enabled, the compiler warns if it finds multiple methods with different arguments or return types for a given selector - but only if the receiver is "id" or "Class".
You can enable this flag, but you won't get a warning if you had written your statement as follows:
float myValue = [(MyClass*)[myArray objectAtIndex:i] position]+kMyConstant;
Since you explicitly cast from "id" to MyClass* the compiler omits the warning. In this case, the compiler assumes you know exactly what you are doing.
If you had written it as below
float myValue = [[myArray objectAtIndex:i] position]+kMyConstant;
and the flag -Wstrict-selector-match is set, the compiler will warn you - since there is an ambiguity.
In praxis, you would now need to resolve this ambiguity, through explicitly cast to the return type you expect (as you did).
> 2. What possible side effects could such a mismatch lead to? Is it really possible that this could lead to round() returning NaN (sometimes)?
I would say, if there are more than one possibly return types for the same selector, the code is illegal unless you explicitly type cast to the correct return type. Of course, assuming it is actually the type you expect. Otherwise, it is a programmer error.
If you erroneously cast to a wrong type, or if there is an ambiguity the side effects will be random. I guess, its very possibly that you see this effect.
Regards
Andreas
_______________________________________________
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