Re: Why does NSArray count return NSUInteger?
Re: Why does NSArray count return NSUInteger?
- Subject: Re: Why does NSArray count return NSUInteger?
- From: Quincey Morris <email@hidden>
- Date: Mon, 30 May 2011 14:34:24 -0700
On May 30, 2011, at 13:45, julius wrote:
> Hilarity and riot.
Glad to have been of service.
> Here is a nice instance that I think quite germane.
>
> The input parameter to NSArray's objectAtIndex: is an NSUInteger.
> Both these code snippets work perfectly (they retrieve element 3).
> zStr = [zAry objectAtIndex:3.1];
> and
> CGFloat zF1 = 3.2;
> zStr = [zAry objectAtIndex:zF1];
>
> I'm sure that by setting the right flags one could get warning messages to appear.
OK, but why are you picking on NSArray? Here's another method that exemplifies exactly the same problem:
- (id) iMadeThisUp: (unsigned int) theNumberIFirstThoughtOf { ... }
It's a defect in ObjC that comes directly from a defect in C.
Now that we've reduced this to a C issue, let me try to provoke more hilarity and riot by re-characterizing your objection:
-- You want integer calculations in C to be carried out in a unique abstract numerical space.
By "unique", I mean that there aren't different rules depending on the types of the integers involved. By "abstract" I mean that the numerical range is conceptually infinite. The only constraint is that the result should be representable in (?) the variable type of the destination variable, or something like that.
This is a perfectly sensible idea. It is in fact a lot like how C works with floating point -- intermediate calculations are performed in type 'double', even if the values are type 'float'. In effect, C has no "arithmetic" type 'float', only a "storage" type 'float'. (Terminology applied loosely here.)
Unfortunately, somebody decided a long time ago, the same can't be done for integers, because there's no infinite-range numerical space available to machine computation (in any way that mainstream hardware supports directly), and no single finite-range space that (as in the floating point case) encompasses the others.
As a result, in C, the numerical space of the expression really does depend on the types of the variables involved. The arithmetic operators, even + and -, *mean* different things for signed and unsigned arithmetic. You should read that last sentence twice, because it's the heart of the matter.
There is, additionally, a horrible mish-mash of conversion rules that mean that much of the time you can ignore the difference when writing source code, but at your peril.
You want different conversion rules? Fine. You want warning messages? Fine. You want a unique abstract numerical space? Fine. You want type-independent arithmetic operators? Fine. You want to get us a new language? Fine. But you can't insist of writing code for a language-roughly-similar-to-C-but-not-quite-the-same-thing and then complain because it isn't C. *There's* the riot and hilarity. ;)
_______________________________________________
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