On Jan 17, 2011, at 08:28, Sean McBride wrote: > On Sat, 15 Jan 2011 18:51:52 +0000, Thomas Davie said: > >> NSNotFound could have *any* value, and in fact its value could change >> from cocoa version to cocoa version. Stop looking! > > If they change it, they'll break binary compatibility with existing > apps. So it won't be changing. (Which isn't a reason to bypass it, but...)
Some further musings on this subject: 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. FWIW _______________________________________________ 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
