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/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Reply via email to