Re: [iPhone] Floating Point numbers with .f and without .f Suffix
Re: [iPhone] Floating Point numbers with .f and without .f Suffix
- Subject: Re: [iPhone] Floating Point numbers with .f and without .f Suffix
- From: Quincey Morris <email@hidden>
- Date: Tue, 12 Oct 2010 01:04:07 -0700
On Oct 11, 2010, at 23:58, Tharindu Madushanka wrote:
> I would like to clarify about the usage of .f suffix when using floating
> point numbers related to iPhone. I read .f is to tell the compiler about the
> number is a float at start avoid any casting.
>
> So when we use CGRectMake(CGFloat x, CGFloat y, CGFloat width, CGFloat
> height) I usually see people use without .f.
>
> For example, CGRectMake(0,0,320,460) instead of
> CGRectMake(0.0f,0.0f,320.0f,460.0f)
>
> Is there any minor performance of using either approach. Could someone
> kindly clarify on this.
(This isn't really a Cocoa question, BTW.)
There are two separate issues.
1. The compiler follows a very well-defined set of rules when converting between numeric type, defined by the C language spec. Therefore, there's normally no confusion about writing code which depends on conversion -- that is, which depends on the rules being the rules. It basically comes down to a matter of personal preference**.
2. Every reasonable, modern compiler recognizes compile-time constants, and can do such type conversions at compile time. Therefore, there are *no* run-time performance considerations resulting from the choice of one form of another. I doubt there is any measurable compile time performance consideration, either.
**Note: There are situations where it's wrong to use a constant of the wrong type, but that's not because it's a bad idea to use the "wrong" type, but because the rules for these situations limit or prevent the compiler from doing the conversion for you. I'm thinking specifically of numeric constants in variable argument lists (e.g. printf parameters), where the compiler doesn't have any information that would allow it to do a conversion. In such a case, you get what you ask for, even if it's not what you wanted.
_______________________________________________
Cocoa-dev mailing list (email@hidden)
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:
This email sent to email@hidden