And as a side note, NSNotFound != kCFNotFound. This has caught me out a couple of times in code that is dealing with both NS and CF objects.
Matt On 18 Jan 2011, at 04:58:06, Uli Kusterer wrote: > On 17.01.2011, at 19:50, Quincey Morris wrote: >> 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. > > Which is good to know if you want to use NSNotFound in your own classes, but > largely irrelevant if it is an index into a collection of objects, like > NSArray. Because in that case, just storing the pointers to these items in an > array (which takes 4 bytes in 32-bit, 8 in 64-bit) already restricts the > number of items to a value below NSIntegerMax. > > After all, you'd already run out of address space around NSIntegerMax / 2 > (NSUIntegerMax / sizeof(id), i.e. NSUIntegerMax / 4). And since you need > memory for system libraries, and for the NSArray and stored object(s) itself > (it could be an array containing the same object over and over, though), plus > a stack and general memory management overhead, you'll lose a few bytes more. > > Considering Apple's frameworks change size with each system release, I don't > think there is a way to reliably calculate an upper limit. If your > application is likely to even vaguely get near the ballpark of NSIntegerMax / > 2, you should probably look into implementing a virtual memory-like mechanism > that swaps in/out objects from disk as needed. > > -- Uli Kusterer > Sole Janitor > http://www.the-void-software.com > > > > _______________________________________________ > > 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/mgough%40humyo.com > > This email sent to mgo...@humyo.com _______________________________________________ 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
