Re: Why does NSArray count return NSUInteger?
Re: Why does NSArray count return NSUInteger?
- Subject: Re: Why does NSArray count return NSUInteger?
- From: Roland King <email@hidden>
- Date: Mon, 30 May 2011 21:31:05 +0800
.. going back on list ..
On 30-May-2011, at 9:18 PM, julius wrote:
>
> On 30 May 2011, at 12:28, Roland King wrote:
>
>>
>>
>>> In what contexts is that output going to be used?
>>> I think that like me people will tend to use it in contexts to do with accessing array elements
>>> e.g. x = [ary objectAtIndex:[ary count]-2];
>>
>> well if you haven't already confirmed that [ary count ] can never be less than 2, or checked that [ ary count ] is larger than or equal to 2, or then you shouldn't be trying to get the element at ( [ ary count ] - 2 ), you're going to fail whatever the data type is, that's a logic error.
> The intention of the example was to show a context.
> Of course it would be an error if I did not check blah.
If you check then there is no issue with that statement and it works perfectly well.
>
>>
>>> or modifying behaviour according to array size
>>> e.g. if(k1 < ([ary count] - k2)) {…
>>
>> again - if you don't already know that [ ary count ] >= k2, you should't subtract k2 from it. if you don't know and want to do that statement with one check use
> ditto.
ditto
>>
>> If( ( k1 + k2 ) < [ ary count ] ) ..
> please do not rewrite my examples
> I said
> if(k1 < ([ary count] - k2)) {
> This is not about optimisation
> but the reason why the designers chose to have NSArray count return an NSUInteger.
Neither was my 'rewrite' about optimization. Again if you know that [ ary count ] >= k2 then your if() statement will work as-written.
>
>>
>>> If we know that a variable is never going to return a negative value and that it is predominantly going to be used in an arithmetic context why force the programmer to think about coercing the type on each occasion of its use when failure to do so risks malfunction?
>>
>> You don't need to coerce it.
> well in the piece of code which gave rise to all this I do, unless I rewrite using umpteen more lines of code.
No you don't. If you use NSUIntegers everywhere and check your bounds as you say you do, you don't need to coerce anything to anything.
>
>> NSUInteger works perfectly well in an arithmetic context. The programmer needs to ensure that they treat the data type within its limits. You can't add 20,000,000 to an unsigned char and expect it to work, similarly here you have to be aware of the kind of variable you have and treat it appropriately. That If( ( k1 + k2 ) < [ ary count ] ) is a good example of that.
> Precisely the point of my question.
> Why create a linguistic construct that has the potential to create problems if it skips one's mind that NSArray count returns NSUInteger as opposed to NSInteger which would not.
They didn't create a linguistic construct to do anything. They used a variable correct for the type of the data they are representing. As a programmer you need to think every time you subscript an array "am I going outside the bounds of the array doing this", similarly when doing mathematical operations on things which represent 'sizes of things which cannot be smaller than empty'.
>>
>>>
>>> So was it really just because the number of array elements is never -3 that the Cocoa developers decided to make NSArray count return type NSUInteger?
>>
>> Yes. Because NSArrays cannot have less than 0 elements, so there is no point at all having the size of an array have a potential negative domain. It's meaningless. They didn't use a double or a float for size either, because you can't have 2.5 things in an array or look up the point at Array[ 23.4 ], well not with this kind of array.
> Ok. This mixes two types of usage.
> In the case of if(k1 < ([ary count] - k2)) we are speaking about a return value which is used in a variety of contexts.
>
> In the case of ary[x] we are speaking about how we identify a particular array element and in C having a restriction on the type is used to enforce a useful rigour. Other languages might not do this because they have different objectives.
>
> In the if(k1 < ([ary count] - k2)) case I am asking why impose an NSUInteger complication when to do so has the potential to create problems precisely because in other contexts ([ary count] - k2) delivers the more intuitive result.
Again, as long as you have checked that [ ary count ] >= k2 before you do that if(), you're fine. Or you rewrite it with +, as I did, it avoids the issue because it recognizes that sizes can be added, but cannot be subtracted without checking first, because there is no such thing as a negative size. size minus bigger size is not a defined concept.
>
>> They used the datatype which maps onto the thing they are describing, array elements are non-negative integers, so they used NSUInteger.
> So are you saying that the designers made this decision solely because of a particular interpretation of dogma?
No. I am saying that semantically the 'size' of an array is a non-negative integer and thus the correct way to represent it is with a data type which represents non-negative integers.
> Julius
>
> http://juliuspaintings.co.uk
>
>
>
_______________________________________________
Cocoa-dev mailing list (email@hidden)
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:
This email sent to email@hidden