Check out the String Format Specifiers to see how to format NSLog statements. It's easy to get lazy with NSLog because objects have a built-in -description method that returns a formatted string. For scaler values, you have to use the proper formatter.
Because precision changes as you move from hardware to hardware, it's better to get in the habit of using object conversions to log values. In this case:
NSLog(@"%@", [[NSNumber numberFromInt:myObject.myId] stringValue]);
This will print correctly always.
Edit#1: I apologize. I was sleep deprived when I wrote the above. What I actually intended was to warn against using a simple
NSInteger as well as printing with
Consider the following run on 64-bit hardware.
NSLog(@"x=%d",x); //prints x=2147483647
NSLog(@"n=%d",n); // prints n=-1
NSLog(@"n=%@",[[NSNumber numberWithInteger:n] stringValue]); // prints n=9223372036854775807
In the old days of 8-bit systems, you ran into problems with problems with using 8-bit 'int' all the time. Running a for-loop with more than 256 iterations required a
long. With a 32-bit
int you won't see those kinds of issues and will never develop the habit of tracking the size of your
This can lead to pernicious bugs that are nearly impossible to track down because they only occur with very specific and rare values in the data.
Writing for the iPhone (or other future mobiles/platforms) means writing on potentially highly variable hardware just like we had to do in the old days. It's best to acquire the habit early of using system and API specific definitions.
where myId is int, console gives some
hight number like 70614496.
(1) If it prints a different number each time you run, then you're probably assigning a pointer to the int when you set it. The NSLog is correctly printing the value of the pointer as an int.
(2) if it prints the same number each time, the you probably have an overflow issue like in my first edit above.
In either case, you need to look at code where you assign the value to the
id property and not where you print it.