On Jan 17, 2011, at 11:50 AM, Quincey Morris wrote:
Yes, in one sense the actual value should be irrelevant, but in fact
when NSNotFound is a possible value of a scalar that's truly numeric
(such as a count or an index) you really *do* need to know what
NSNotFound is. For example, you have to be careful not to increment
a numeric quantity into NSNotFound.
In this kind of situation (e.g. the documentation says "returns a
NSUInteger value representing the index of the matching item, or
NSNotFound if no match is found") the usable value range is really
0 .. NSNotFound-1. That imposes a practical limit on the number of
items, which the developer needs to know.
In a slightly larger, conceptual sense, this means that unless you
want to obsess over the specifics of *every* frameworks parameter
*every* time you use one, the *practical*, everyday-use range of
NSUInteger is 0 .. NSIntegerMax, not 0 .. NSUIntegerMax. In 32-bit,
that's a 2 Gig item limit, not 4 Gigs.
I have been implementing some code which interoperates with a
NSArrayController subclass. Cognizance of the numeric value of the
indexing boundary conditions was a coding requirement. I was almost on
the right path but got confused with 32-bit/64-bit and NSInteger/
NSUInteger. Thanks for stating this with such clarity.
--Richard Somers
_______________________________________________
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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
