Should we use the 'f' suffix for float constants?

[kodecocodes]

Should we use the 'f' suffix for float constants?

[ricardo-rendoncepeda]

This is very important in graphics applications, so I vote +1 on the suffix. Alternatively, we can leave it out and I can clarify it's importance in any of my OpenGL ES tutorials.

I always use the f as I believe it acts as a hint to the compiler, as well as the coder.

Sent from my iPhone

On 8 Nov 2013, at 17:15, ColinEberhardt [email protected] wrote:

The current style guide does not detail whether we should or should not, but the 'f' suffix is lacking in one of the examples.

static const CGFloat RWImageThumbnailHeight = 50.0;
I am on the fence about this one.

—
Reply to this email directly or view it on GitHub.

[hollance]

I always use them (except for things that are doubles, of course, such as NSTimeInterval).

But I've been wondering: does it make a difference on 64-bit?

[pietrorea]

I would add in the 'f' if only to hint to the reader that there's more than just integers and decimals to consider.

[gregheo]

I don't think it's worthwhile. My understanding is that bare 10.0 is a double, and the point of 10.0f is to explicitly make it a float. float foo = 10.0; will convert down just fine but double foo = 10.0f; will lose precision. We're in C-based static type land so I say let the compiler convert or optimize as it sees fit.

Plus it just looks weird and it's redundant. The decimal .0 part already shows it to be a floating-point number.

[moayes]

I agree with @gregheo.

[icanzilb]

@gregheo Does that mean you're also fine with

float foo = 10; 

[gregheo]

I write float foo = 10; all the time. Again, the type says it's a float so there's no strict need to say 10.0.

That said: for the style guide, I would stick with float foo = 10.0; (still without the f). That avoids the surprise of say float foo = 10 / 3; being 3 rather than 3.33333.

[icanzilb]

great, my point exactly

[ndubbs]

I agree that we should set the value like float foo = 10.0; instead of float foo = 10;.

Getting back to the original line of code, should there be any changes?
static const CGFloat RWImageThumbnailHeight = 50.0;

[gregheo]

Small change (and just a small can of worms, I hope):

static CGFloat const RWImageThumbnailHeight = 50.0;

Rationale: I know both CGFloat const and const CGFloat work, but this fits the "read the type right-to-left" thing. More complicated when pointers are involved of course, as here:
http://stackoverflow.com/questions/1143262/what-is-the-difference-between-const-int-const-int-const-int-const

But, objects are pointers so it's good to have an order that makes it easy to reason through NSString const * vs NSString * const.

[hollance]

It turns out that CGFloat is a double on 64-bit, so dropping the "f" suffix makes sense.

[John-Lluch]

Just for those who think that an 'f' can be a hint or whatever to the compiler; It does not work like that. The three following statements will produce EXACTLY the same compiled code

float foo = 10.0;
float foo = 10.0f;
float foo = 10;

The compiler will just create a 'foo' variable with the float value 10.0f in it. There are no precision issues at all on any of the above. They produce identical code.

It hails from C.

Floating point literals are double precision by default. Adding the f suffix informs the compiler to treat them as single precision.

Mic Pringle
Sent with Sparrow (http://www.sparrowmailapp.com/?sig)

On Wednesday, 15 January 2014 at 21:30, John Lluch Zorrilla wrote:

Just for those who think that an 'f' can be a hint or whatever to the compiler; It does not work like that. The three following statements will produce EXACTLY the same compiled code
float foo = 10.0;
float foo = 10.0f;
float foo = 10;
The compiler will just create a 'foo' variable with the float value 10.0f in it. There are no precision issues at all on any of the above. They produce identical code.

—
Reply to this email directly or view it on GitHub (#23 (comment)).

[John-Lluch]

Hi, micpringle, my point was that for the single case of a declaration with an assignment, any of the above produces the same. This is because the compiler implicitly converts any of the them to a float (32 bits) at compile time, not at running time. In fact, any constant expression will be converted to a single value of the appropriate type at compile time. Said that, it is true that 10.0 is implicitly a double, but this only has an effect when used in an expression. For example 10.0/3 will not produce the same than 10.0f/3. The first one is 3.333... as a double and the second one is 3.333... as float. If you assign 10.0f/3 to a double you will loose precision.