Re: Can an NSArray ever have a count of -1?
Re: Can an NSArray ever have a count of -1?
- Subject: Re: Can an NSArray ever have a count of -1?
- From: Quincey Morris <email@hidden>
- Date: Fri, 19 Feb 2016 22:02:54 -0800
- Feedback-id: 167118m:167118agrif8a:167118sW6yQNrh1x:SMTPCORP
On Feb 19, 2016, at 21:30 , Gerriet M. Denkmann <email@hidden> wrote:
>
> One can NOT force NSUInteger to be different sizes. It will always be 4 bytes on 32 bit systems, and 8 bytes on 64 bit ones.
>
> 32 bit without DNS_BUILD_32_LIKE_64
> NSUInteger = int;
> 32 bit with DNS_BUILD_32_LIKE_64
> NSUInteger = long (but long = int)
>
> 64 bit (regardless of DNS_BUILD_32_LIKE_64)
> NSUInteger = long (but long > int)
Ah, yes, sorry, I forgot. It’s not about the length, it’s about the type. But then I think NS_BUILD_32_LIKE_64 is doubly useless:
— The difference between int and long is itself ABI-breaking. The Obj-C runtime encodes types as single characters, and int and long may encode as different characters, even when they have the same length. This is going to break stuff. That’s why NS_BUILD_32_LIKE_64 was an option you had to choose to use — it breaks ABI compatibility with 3rd-party frameworks that existed before the transition, or were compiled with non-NS_BUILD_32_LIKE_64 rules after the transition.
— The issue with string formats is about the number of bytes, not the compile-time type, because it’s about the way arg lists are constructed by the compiler. Again, its correctness depends on external knowledge that NSUInteger and long are the same number of bytes, which I claim is a (minor) drawback to your approach**. Apple’s recommendation is correct absolutely because “%lu" *matches* ‘long’ and “(long) anyValue” *is* long. You don’t need to know what long (or NSUInteger) is.
** I admit, that’s exactly the approach I used from about 2006 to 2008, happy to avoid casting the variables. Once the iOS SDK appeared, I started casting again. Later, I switched over to %tu and stopped casting. Now that I code almost exclusively in Swift, the problem has largely disappeared, because ‘"\(someValue)"' is a lot easier*** than ‘[NSString stringWithFormat: "%lu", (someCast) someValue]’.
*** Although, AFAIK, the Swift formatting is currently unlocalized, whereas NSString formatting of numeric values has been localized for the last 2-3 years. This may be something that affects you.
_______________________________________________
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