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: Tony Romano <email@hidden>
- Date: Fri, 03 Jun 2011 00:06:04 -0700
- Thread-topic: Methods with the same name but different return types
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.
-tony
On 6/2/11 6:38 AM, "Eyal Redler" <email@hidden> 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...
>2. What possible side effects could such a mismatch lead to? Is it really
>possible that this could lead to round() returning NaN (sometimes)?
>
>TIA
>
>
>Eyal Redler
>--------------------------------------------------------------------------
>----------------------
>"If Uri Geller bends spoons with divine powers, then he's doing it the
>hard way."
>--James Randi
>www.eyalredler.com
>
>
> _______________________________________________
>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
>
_______________________________________________
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