I tend to use CGFloat all over the place, but I wonder if I get a senseless "performance hit" with this. CGFloat seems to be something "heavier" than float, right? At which points should I use CGFloat, and what makes really the difference?
+6
A:
CGFloat is a regular float on 32-bit systems and a double on 64-bit systems
typedef float CGFloat;// 32-bit
typedef double CGFloat;// 64-bit
So you won't get any performance penalty.
weichsel
2009-08-12 08:31:47
Well, you use twice as much memory, if you're worried about memory.
Tyler
2009-08-12 08:58:29
Only on 64-bit, though.
Quinn Taylor
2009-08-12 13:09:59
the iphone is 32 bit?
HelloMoon
2009-08-12 20:06:13
Correct, iPhone OS is 32-bit. If you think about it, the iPhone isn't pushing the 4GB RAM limitation of 32-bit, nor is it using an Intel processor (for which 64-bit is faster than 32-bit). Plus, it's using Modern Runtime (as opposed to Legacy Runtime of 32-bit on the desktop — wearch SO for these terms if you're curious) so it can do basically everything 64-bit OS X can. Perhaps someday we'll see a device that runs iPhone OS and is 64-bit, but currently there are none.
Quinn Taylor
2009-08-12 20:35:57
+14
A:
As @weichsel stated, CGFloat is just a typedef for either float or double. You can see for yourself by Command-double-clicking on "CGFloat" in Xcode — it will jump to the CGBase.h header where the typedef is defined. The same approach is used for NSInteger and NSUInteger as well.
These types were introduced to make it easier to write code that works on both 32-bit and 64-bit without modification. However, if all you need is float precision within your own code, you can still use float if you like — it will reduce your memory footprint somewhat. Same goes for integer values.
I suggest you invest the modest time required to make your app 64-bit clean and try running it as such, since most Macs now have 64-bit CPUs and Snow Leopard is fully 64-bit, including the kernel and user applications. Apple's 64-bit Transition Guide for Cocoa is a useful resource.
Quinn Taylor
2009-08-12 13:16:48
I think I get it now. But on the iPhone it seems to not matter much, right?
HelloMoon
2009-08-12 20:08:03
On the iPhone as we know it, no. However, it's always wise to future-proof code, and this would make it easier to safely reuse the same code for OS X.
Quinn Taylor
2009-08-12 20:31:20
@Quinn Taylor, so you're saying, basically, NEVER use a float or double directly since then you'd be tied to the processor architecture (and I thought fast JVMs solved this years ago :)). So what primitives are safe? `int`?
Yar
2010-07-09 15:21:41
I didn't say NEVER use a primitive directly. There are times that straight primitives can be problematic, such as if a variable may conceivably be used to store data which could overflow, such as on 64-bit. In general, using architecture-dependent typedefs is safer, in that code is less likely to explode on a different architecture. However, sometimes using a 32-bit type can be completely safe and save you memory.The size of primitives may be less of an issue in a JVM, but Obj-C and C are compiled, and mixing 32 and 64 bit libraries and code is indeed problematic.
Quinn Taylor
2010-07-09 22:10:09