Re: NSInteger vs int vs int32_t
Re: NSInteger vs int vs int32_t
- Subject: Re: NSInteger vs int vs int32_t
- From: Charles Srstka <email@hidden>
- Date: Mon, 02 Jul 2012 17:28:34 -0500
On Jul 2, 2012, at 3:10 PM, Jens Alfke wrote:
> On Jul 2, 2012, at 12:06 PM, Chris Hanson wrote:
>
>> NSInteger and NSUInteger also have the advantage of having the same @encode() on 32-bit and 64-bit, which can be important for binary compatibility of archives and IPC between architectures, depending on how you do it.
>
> How can they? They're different sizes. Even if your protocol prefixes them with a type-code or length to get around that, you have another problem: if you write an NSInteger in 64-bit and read it in 32-bit, you're potentially losing data. (The same situation there's a compiler warning for when you assign to a variable of smaller width.)
>
> If you want binary compatibility you should definitely be using types that have an explicit guarantee of size, like int32_t or int64_t.
When I’m parsing a binary file format, of course I always use the explicitly-sized types. Most of the time, that’s not what you’re doing, though, and for general-purpose stuff NS(U)Integer is better.
> I really don't understand the thought behind creating NSInteger. It seems dangerous to have a 'standard' type whose size isn't fixed. It leads to mistakes like storing a file size in an NSUInteger — that's fine in 64-bit, but in a 32-bit app it blows up on large files. I thought we'd already learned this lesson with the old C 'int' type, which has been giving people cross-platform problems since the 1970s.
NSInteger is always equal to the native integer size of the host machine; 32 bits in 32-bit, 64 bits in 64-bit. I would imagine this helps performance, as the processor will be dealing with its native integer type. Also, for indexes and offsets, things like -[NSData length], it makes sense; a NSUInteger ensures that it will be able to hold any value that’s legal on the architecture. If -[NSData length] had been defined as a uint32_t, that would have caused forward compatibility problems with the move to 64-bit.
And really, if you are storing NSUIntegers to the disk, you’re just doing it wrong. XML is what you should be using for most new formats these days; when you have to read/write in binary formats, that’s what the u?int[0-9]+_t formats are for. Using a uint32_t in cases where there’s no real reason to require that the integer be exactly 32 bits wide, though, doesn’t seem to provide any benefit.
Charles
_______________________________________________
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