type of NSNotFound
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. -- matt neuburg, phd = m...@tidbits.com, http://www.apeth.net/matt/ pantes anthropoi tou eidenai oregontai phusei Programming iOS 6! http://shop.oreilly.com/product/0636920029717.do RubyFrontier! http://www.apeth.com/RubyFrontierDocs/default.html TidBITS, Mac news and reviews since 1990, http://www.tidbits.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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: type of NSNotFound
On 20 Jul 2013, at 23:06, Matt Neuburg m...@tidbits.com 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. Quite simply, there isn't enough memory available in the address space to ever create a useful array containing NSIntegerMax number of objects. ___ 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: type of NSNotFound
On Jul 21, 2013, at 0:06, Matt Neuburg m...@tidbits.com wrote: 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. It doesn’t matter. An array holds object pointers, so you can only have 1/4th (or 1/8th in 64 bit) of the number of items of available address space to begin with (otherwise, where’d you store the pointers). Or rather, less than that, because of system libraries and the NSArray object itself and your application’s code and ... This way, NSNotFound works both for NSInteger and NSUInteger and is the same value, and you don’t need an additional NSUNotFound. Cheers, -- Uli Kusterer “The Witnesses of TeachText are everywhere...” http://zathras.de ___ 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: type of NSNotFound
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 m...@tidbits.com 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 (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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: type of NSNotFound
Er, I mean 2**67 bytes. My brain was stuck on 32 bit pointers. On Jul 20, 2013, at 15:30 , Quincey Morris quinceymor...@rivergatesoftware.com wrote: or about 2**35 bytes ___ 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: type of NSNotFound
Quite simply, there isn't enough memory available in the address space to ever create a useful array containing NSIntegerMax number of objects. Thx to all - very interesting, and my mind is set at ease. (I am mostly worried about whether there are any practical gotchas lurking behind the habit of comparing to NSNotFound, but it doesn't sound as if there are.) m. -- matt neuburg, phd = m...@tidbits.com, http://www.apeth.net/matt/ pantes anthropoi tou eidenai oregontai phusei Programming iOS 6! http://shop.oreilly.com/product/0636920029717.do RubyFrontier! http://www.apeth.com/RubyFrontierDocs/default.html TidBITS, Mac news and reviews since 1990, http://www.tidbits.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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
NSNotFound signed???
I've just been shocked to find out that NSNotFound is defined by the framework as NSIntegerMax, that is maximal value of *SIGNED* integer, which in 64 bit architecture is 0x7fff. I used to think that it should be NSUIntegerMax, that is the maximal value of *UNSIGNED* integer, corresponding to 0x. It had to be so because NSNotFound value is used in many places of the system framework for working with array indexes, for example, -[NSArray indexOfObject:] returns unsigned NSUInteger indexes, *BUT* it returns NSNotFound if the element is not found. But NSNotFound should be a valid index in the middle of possible unsigned integer range! It means that even though the NSArray allows NSUIntegerMax of elements, you can actually use only NSIntegerMax elements, because starting from NSIntegerMax you will get screwed up by things like indexOfObject: How come? ___ 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: NSNotFound signed???
On Jun 12, 2013, at 00:11 , Oleg Krupnov oleg.krup...@gmail.com wrote: I've just been shocked to find out that NSNotFound is defined by the framework as NSIntegerMax, that is maximal value of *SIGNED* integer, which in 64 bit architecture is 0x7fff. I used to think that it should be NSUIntegerMax, that is the maximal value of *UNSIGNED* integer, corresponding to 0x. It had to be so because NSNotFound value is used in many places of the system framework for working with array indexes, for example, -[NSArray indexOfObject:] returns unsigned NSUInteger indexes, *BUT* it returns NSNotFound if the element is not found. But NSNotFound should be a valid index in the middle of possible unsigned integer range! It means that even though the NSArray allows NSUIntegerMax of elements, you can actually use only NSIntegerMax elements, because starting from NSIntegerMax you will get screwed up by things like indexOfObject: How come? It's the only extreme-ish compile-time constant that's representable unambiguously in both signed and unsigned expressions. C has funny rules for conversions in compile-time expressions, so that makes using (for example) 0x treacherous in other ways. As long as you're aware of it, it's not a major problem in the NSArray case, since it would be extremely rare to actually want array indexes that don't fit into 63 unsigned bits, as opposed to 64. In particular, there isn't enough address space to create a NSArray containing even NSIntegerMax pointers. The easiest conceptual adjustment here is to think of NSUInteger as a 63-bit number, not a 64-bit number. Actually, the weird value for NSNotFound is not really the most treacherous aspect. Far more dangerous is the fact that it's not generally safe to archive (i.e. use the NSCoder protocol on) NSNumber objects whose value represents NSNotFound, because the value is architecture dependent. If you archive a 64-bit NSNotFound, it's no longer NSNotFound when unarchived on a 32-bit architecture, and vice versa. ___ 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: NSNotFound signed???
On Jun 12, 2013, at 00:42 , Quincey Morris quinceymor...@rivergatesoftware.com wrote: If you archive a 64-bit NSNotFound, it's no longer NSNotFound when unarchived on a 32-bit architecture, and vice versa. Oops, just to clarify: I don't mean there's anything wrong with the archiving or unarchiving per se. It's no longer NSNotFound when you encode/decode a NSUInteger/NSInteger variable, because there'll be truncation or incorrect sign extension of the scalar value, in one direction or the other. ___ 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: NSNotFound signed???
there isn't enough address space to create a NSArray containing even NSIntegerMax pointers. I knew someone will say this. Who needs more than 640 KB RAM after all? :) © Bill Gates What if I have sparse array etc. One higher bit is actually twice as many elements. Why having NSUInteger at all if you can't use more than NSIntegerMax? This doesn't seem right. Anyway thanks for your time, Quincey! On Wed, Jun 12, 2013 at 10:52 AM, Quincey Morris quinceymor...@rivergatesoftware.com wrote: On Jun 12, 2013, at 00:42 , Quincey Morris quinceymor...@rivergatesoftware.com wrote: If you archive a 64-bit NSNotFound, it's no longer NSNotFound when unarchived on a 32-bit architecture, and vice versa. Oops, just to clarify: I don't mean there's anything wrong with the archiving or unarchiving per se. It's no longer NSNotFound when you encode/decode a NSUInteger/NSInteger variable, because there'll be truncation or incorrect sign extension of the scalar value, in one direction or the other. ___ 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: NSNotFound signed???
Le 12 juin 2013 à 10:14, Oleg Krupnov oleg.krup...@gmail.com a écrit : there isn't enough address space to create a NSArray containing even NSIntegerMax pointers. I knew someone will say this. Who needs more than 640 KB RAM after all? :) © Bill Gates This has nothing to do with the amount of available RAM. The limitation is with the virtual memory system. If you can have 2^64 bytes of address space, you can a max store 2^64 / sizeof(void *) pointers. What if I have sparse array etc. If you have sparse array, so just don't write it using NSNotFound. We are talking about a well defined class and well defined API, not a potential non existing API that can use the wrong constant. One higher bit is actually twice as many elements. Why having NSUInteger at all if you can't use more than NSIntegerMax? This doesn't seem right. Because you want to use an unsigned number to defined the number of element (having a negative number of elements does not make sense), and it is pointless and inefficient to to defined and used a 56bit integer type on actual architectures. -- Jean-Daniel ___ 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: NSNotFound signed???
This has nothing to do with the amount of available RAM. The limitation is with the virtual memory system. If you can have 2^64 bytes of address space, you can a max store 2^64 / sizeof(void *) pointers. You misunderstood, I wasn't talking about RAM. It was merely an illustration of how an assumption that seemed justified basing on some then current technical limits, in hindsight turned out ridiculous and crippling after the technical limits were pushed further. Never mind. If you have sparse array, so just don't write it using NSNotFound. We are talking about a well defined class and well defined API, not a potential non existing API that can use the wrong constant. That's exactly the pitfall that I felt into, and that's the point of my original post. I thought it was safe to use NSNotFound with my classes because it is so commonly used with NSUInteger array indexes in the framework, but it turns out to be unsafe, and without any documented cautions. One higher bit is actually twice as many elements. Why having NSUInteger at all if you can't use more than NSIntegerMax? This doesn't seem right. Because you want to use an unsigned number to defined the number of element (having a negative number of elements does not make sense), and it is pointless and inefficient to to defined and used a 56bit integer type on actual architectures. You seem to be ardently defending the idea that it's somehow okay to lose half of possible array indexes just because. I admit there may be good reasons for this, but I'm yet to see why exactly. ___ 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: NSNotFound signed???
On Jun 12, 2013, at 3:01 AM, Oleg Krupnov oleg.krup...@gmail.com wrote: You misunderstood, I wasn't talking about RAM. It was merely an illustration of how an assumption that seemed justified basing on some then current technical limits, in hindsight turned out ridiculous and crippling after the technical limits were pushed further. It’s not a technical limit, it’s a mathematical limit. An n-bit address space simply cannot hold 2^n pointers. (I think the limit is 2^(n - n/8) … but of course even at that limit you wouldn’t have room for any objects for the pointers to point to!) If you want to implement a sparse array that can support 2^64 items, go for it, but you’ll need some mechanism other than NSNotFound to indicate when a value isn’t found. —Jens ___ 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: NSNotFound signed???
On Jun 12, 2013, at 01:14 , Oleg Krupnov oleg.krup...@gmail.com wrote: What if I have sparse array etc. One higher bit is actually twice as many elements. Why having NSUInteger at all if you can't use more than NSIntegerMax? This doesn't seem right. -- If you're talking about NSArray, there's no such thing as a sparse array. That's why NSNotFound == NSIntegerMax works -- it's a value you can *never* use as a NSArray index, *not* an artificial limitation on the range of indexes. -- The same is true for (non-sparse) C arrays. -- If you implement a sparse array yourself, and you want to use the full index range, then you likely wouldn't use NSNotFound as a marker at all. If you need a marker, you'd likely use 0 or NSUIntegerMax, right? ___ 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: NSNotFound
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
Re: NSNotFound
On Jan 18, 2011, at 9:58 AM, Matt Gough wrote: 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. Whoo yeah! That was a fun afternoon ... Cheers, -- Uli Kusterer The Witnesses of TeachText are everywhere... ___ 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
Re: NSNotFound
On Sat, 15 Jan 2011 18:51:52 +, 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...) -- Sean McBride, B. Eng s...@rogue-research.com Rogue Researchwww.rogue-research.com Mac Software Developer Montréal, Québec, Canada ___ 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
Re: NSNotFound
On Jan 17, 2011, at 08:28, Sean McBride wrote: On Sat, 15 Jan 2011 18:51:52 +, 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
Re: NSNotFound
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
Re: NSNotFound
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
NSNotFound
NSNotFound is formally defined as NSIntegerMax. But the framework methods returning NSNotFound are typically typed NSUInteger. Is there a technical reason why NSNotFound is not defined as NSUIntegerMax? --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
Re: NSNotFound
On 15 Jan 2011, at 18:43, Richard Somers wrote: NSNotFound is formally defined as NSIntegerMax. But the framework methods returning NSNotFound are typically typed NSUInteger. Is there a technical reason why NSNotFound is not defined as NSUIntegerMax? 1) Because it's usable for NSInteger too. 2) By looking at these values you're breaking the abstraction barrier. NSNotFound could have *any* value, and in fact its value could change from cocoa version to cocoa version. Stop looking! Bob___ 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
