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: Sat, 04 Jun 2011 09:17:10 +0200
On Jun 3, 2011, at 3:23 PM, Eyal Redler wrote:
> I think my original post wasn't clear enough. I saw the side effects (like round() retuning NaN) when I _wasn't_ casting.
round is declared in fp.h as follows:
double round(double x);
So, if you directly provide the argument with the result of position - without type casting ...
double x = round( [[myArray objectAtIndex:i] position]+kMyConstant );
the code is - IMHO - illegal, if there is ambiguity of the method position:
The compiler still has two choices to select from two methods:
a) - (int) position;
b) - (float) position;
There is no Objective-C specification, but my feeling is, that it is irrelevant which type of parameter round() has which would possibly prefer one method candidate over the other. The compiler will promote any return value (either int or float) to double without mentioning.
> Once I've cast, the problems disappear.
This seems logical, since you explicitly told the compiler how to interpret the result type, assuming the type cast was correct.
> I just can't be 100% sure that the problems are directly related because the side effects were never consistent and I also don't really understand how these effects could take place considering the fact that both integer and float (on my 32bit application) are the same size.
To be honest, I have no idea what *in detail* the compiler will do on the callers side in case of ambiguity of the returned result. The caller code will simply *interpret* the result as either "int" or "float" depending on what the compiler has chosen for the caller. Note also, that at runtime the caller may be completely right when interpreting the result, and for another object the caller can be complete wrong interpreting the result. This is the case when your array contains objects of different classes, and these respond to "position" having each a different return type. Note, that there is no *type cast*, the result - that is the bits on the stack which have been set by the method position will be simply *interpreted* as what the caller think it is.
But, consider this:
Suppose, there is a method
a) -(double)position and
b) -(short)position
short x = 0;
short y = 0;
short z = [[myArray objectAtIndex:i] position];
So, sizeof(double) > sizeof(short).
Suppose, the compiler will select the short return type, can we be sure the caller's stack is still valid when the receiver returns a double? That is, x and y are not touched in some accidentally way? I hope so. But z would contain junk.
(Need to investigate this)
>
> So, I understand that this statement:
>
> float myValue = [[myArray objectAtIndex:i] position]+kMyConstant;
>
> Gives me a bad value for "myValue" if the compiler treats "position" as a method returning integer. But is it possible that this would also cause something like round() retuning NaN for a perfectly normal number? (at least as far as I could see in the debugger)
No, I think there is another issue.
round() is not a method, it is a function. What happens there is precisely defined. Given your description, there should be no problem - assuming the argument is a proper float and not NaN. But note, there are a couple of flavors of the round() function - which may in certain cases throw a floating-point exception (please see man pages).
Tip: When you use round with a float as argument, you should use roundf() which returns a float.
You should also consider the case, that the debugger may not always show the correct values in its variable pane (I experience this occasionally). When in doubt, use a printf or NSLog.
And, I strongly recommend, use unit test cases.
Andreas
>
> 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