Re: type of NSNotFound
Re: type of NSNotFound
- Subject: Re: type of NSNotFound
- From: Quincey Morris <email@hidden>
- Date: Sat, 20 Jul 2013 15:30:56 -0700
There's no mistake. There are several things going on here.
One is that C is a bit funny about compile-time resolution of constants outside the signed (int or long) range, which makes it desirable to avoid having a constant outside the range. Otherwise, unsigned constants may turn into signed constants, and vice versa. (I can never remember the exact scenario, so that's why I'm waving arms a bit. But it's a known C quirk.)
Another is that it's useful for NSNotFound to have one value that can be used in either an signed or unsigned context. That means it has to lie in non-negative signed integer range, and the only practical value meeting those conditions is NSIntegerMax.
Lastly, NSUIntegerMax isn't *outside* the unsigned integer range, it's the last value inside it. However, limiting the range even to half of the theoretical maximum isn't a problem. It isn't possible to have a Cocoa collection of even NSIntegerMax elements, because the memory addressing range isn't big enough to record that many pointers, let alone the objects pointed to. (You'd need NSIntegerMax * 8 bytes for the pointers, or about 2**35 bytes.)
There was a thread about this recently, and I think the take-away is:
-- Having NSNotFound==NSIntegerMax is only a problem in the context of things like sparse arrays that need a full 64 bits of indexing. If you implement such a construct, you'd better stay away from using NSNotFound with it, but there's nothing like that (AFAIK) in Cocoa itself.
-- The real difficulty with NSNotFound is that it's architecture dependent, which means you need to be very careful about NSArchiving it in documents shared between 32- and 64-bit architectures.
On Jul 20, 2013, at 15:06 , Matt Neuburg <email@hidden> wrote:
> On iOS, NSNotFound is defined as NSIntegerMax. However, the index of an NSArray, which is a case where you'd often want to use NSNotFound (e.g. indexOfObject:), is of type NSUInteger.
>
> Isn't there a type mismatch here? It seems to me that NSNotFound ought to be a value *outside* the possible range NSArray index values - which it would be, if NSNotFound were NSUIntegerMax, or if NSArray's indexes were of type NSInteger. As thing are, when you call indexOfObject: and test the result against NSNotFound, you could be getting the wrong answer; if that index happens to be NSIntegerMax (which is only halfway through the available unsigned indexes), it will seem to be NSNotFound when in fact it is an actual index.
>
> I must be wrong about this, since Apple wouldn't make such a basic mistake. So what's *my* mistake? Thx - m.
_______________________________________________
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