Graham Cox wrote: > NSInteger is a typedef for 'long', which size depends on the platform (32/64 > bit), so valueForKey: will wrap it as a NSNumber using type 'long’.
That’s not quite true. While it is the desired effect that NSInteger behave like long, NSInteger was used because the spots in the API where NSInteger is used today used to be of type ‘int’. So on 32 bit, NSInteger is int (which is 32 bits, same as long) and on 64 bit NSInteger is long (which is 64 bits). This means that old 32bit code doesn’t break that relies on these parameters being ints, like calls to NSLog (which would otherwise complain about the use of “%d” instead of “%ld”). Of course that code *will* break when compiled under 64-bit, but the compiler doesn’t know whether a particular 32-bit value should be expanded to 64 bits or not, so it breaking means you see there is an issue and can review and fix it, which you’d have to do anyway on a change between architectures like this. On 14 Jul 2014, at 03:55, Trygve Inda <cocoa...@xericdesign.com> wrote: > So what is the purpose of the NSInteger access within NSNumber eg > integerValue and setIntegerValue ? NSNumber is used both for in-memory access to data (e.g. when you use setValue:forKey:, whether explicitly, or implicitly through bindings, or for use in userInfo dictionaries like on NSNotification and NSTimer) and for serialization of data to disk. NSInteger is a data type intended only for in-memory use. It expands certain memory-limited parameters like array indexes and other memory offsets to 64-bit when compiled and running as a 64-bit app on a 64-bit CPU, while keeping old code written against the 32-bit ABI compiling. The existence of NSInteger support in NSNumber is solely for this in-memory use. It doesn’t really make sense to persist an NSInteger to disk *unless* you never plan to support another architecture. E.g. if your app is for a festival this year and is 64-bit-only, you would be safe to persist an NSInteger to disk. But I’d still consider it bad style. You should use a type that has a known size (or rather, a known range) and stays that way when saving to disk. If you can’t load the larger values in a 32-bit app, at least by loading them as a long long, you get the whole value and can put up an error to the user and refuse to load the file that way. Cheers, -- Uli Kusterer “The Witnesses of TeachText are everywhere...” http://zathras.de _______________________________________________ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
