Re: Cocoa-dev Digest, Vol 8, Issue 383
Re: Cocoa-dev Digest, Vol 8, Issue 383
- Subject: Re: Cocoa-dev Digest, Vol 8, Issue 383
- From: julius <email@hidden>
- Date: Mon, 30 May 2011 15:42:12 +0100
On 30 May 2011, Graham Cox wrote
>
> On 30/05/2011, at 9:03 PM, julius wrote:
>
>> Why did Cocoa developers make the count method return NSUInteger?
>
>
> Because you can't have negative numbers of elements in an array.
>
> It's that simple.
Yes but is that the only reason for doing this?
>
> The reason you're running into trouble is not because this type is unsigned, it's because you are doing arithmetic on it based on faulty assumptions. It's an error to assume that an index is valid just because you computed it to be so. It's always potentially buggy to do things like this:
>
> index = [array count] - 10;
>
> without checking whether what you end up with is in fact a valid index.You are not doing any such checking. The choice of an unsigned type by Cocoa engineers does not make this code suddenly wrong, it was always wrong. Accessing an array with an invalid index will throw an exception. Changing the index type to NSInteger wouldn't change that - the computed index is out of range whether it's expressed as a signed (negative) value or a large unsigned positive value.
Ohhhhhhhhh...... Hmmmm.....
Complicated and I'm not sure my discussing the preceding will not take us away from why I asked the question.
Are you saying that the Cocoa engineers decided that NSArray count return NSUInteger in order to deter people from using [ary count] as part of an equation that accesses an element of an array? Or that they did so in order to prevent people from using the length of an array in a decision making process?
I can't imagine that to be true.
>
>> 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?
>
> It is not predominantly used in an arithmetic context, it's used to tell you the number of items in the array.
by arithmetic context I mean for instance [ary count]+1.
> You might use it to compute an offset into the array, but I would suggest that is pretty unusual. Coercing the type is not the right thing to do in any case - the type is what the type is
So let me get this right.
You are saying that I should write
NSInteger zIntVal = [ary count];
if(3 < (zIntVal - x)) {....
or words to that effect
rather than
if(3 < ((NSInteger)[ary count] - x)) {....
I'll think on it.
or are you saying I should not be using the length of an array in a computation?
But this is all taking us away from the question I asked.
> (another advantage of using unsigned is that it effectively doubles the array's capacity, not that an array that large would ever be feasible).
It is an answer but I can't accept it as being the main reason.
> It's up to you to work with the types provided correctly, not complain that they made a bad design decision when in fact it's your code which is faulty.
I am not complaining. I am asking about the reasons for a decision.
Of course I find decision to have NSArray count return NSUInteger somewhat curious precisely because it seems to me liable to lead to subtle errors in cases where programmers might have forgotten that NSArray count returns etc. etc.
>
> The onus is on you to ensure an array index is in range, or else be prepared for an exception. There's no way of twisting the arithmetic that lets you off doing this.
If I have made any suggestions about twisting arithmetic then I am sincerely sorry. I appear to have failed to express myself clearly and to have used examples that offend.
>
>> 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.
Hmm. OK.
I don't think it is a sufficient reason.
I think the use of NSUInteger in this context is misguided.
My case essentially is
i. that it is a greater potential source of errors than not, e.g. my own example.
ii. that it unnecessarily increases program complexity. This happens every time a data type or command is added to a language. I think that we should never increase the complexity of our programming tools beyond the minimum necessary. This does not mean we should not use NSUInteger simply that our use of it should be judicious and in places where it might be expected and not where it might cause difficulties. Secondly we do not expect c arrays to have negative length thus using NSUInteger is unnecessary. It does not inform and does not provide protection against error since the array length will never be negative. Thus it fulfils no practical purpose - or does it? That is what I would like to know.
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