What I'm trying to do is make it so after they press done on the pop up keyboard, if the text is nil...no object is added to the array, but if its not nil then create the object and add it to the array.

I would be truly astounded if the string-comparison method doesn't test for length equality before comparing character-sequences.

How is length determined? I was under the impression that NSStrings weren't much different from C-strings, which would then mean length is determined by checking each character and seeing if it's a \0 or not... If it's going character by character either way, I don't see why length would be any faster?

How is length determined? I was under the impression that NSStrings weren't much different from C-strings, which would then mean length is determined by checking each character and seeing if it's a \0 or not... If it's going character by character either way, I don't see why length would be any faster?

From the Doc's for NSString

Quote:

The NSString class has two primitive methods—length and characterAtIndex:—that provide the basis for all other methods in its interface. The length method returns the total number of Unicode characters in the string. characterAtIndex: gives access to each character in the string by index, with index values starting at 0.

As a primative method it seem like it needs to fast and cheap.
Also it seems that all NSObjects maintain an Instance size in Bytes* it would seem like the length of the string in characters would be simple function of the size.

Not to mention that to comparing two strings you need two objects where as length is standalone.

I was under the impression that NSStrings weren't much different from C-strings, which would then mean length is determined by checking each character and seeing if it's a \0 or not... If it's going character by character either way, I don't see why length would be any faster?

A simple test to check this:
1. Create a string of 10 million characters.
2. Create a 2nd string that's the same 10 million characters plus an 'X'.
3. Create a 3rd string that's the same 10 million characters plus a 'Y'.
3. Perform isEqual: across the three strings.

If the length-first hypothesis is correct, it should be noticeably faster when the lengths differ, and noticeably slower when the lengths are the same. Any sufficiently large value would work, 10 million is just an example.

A simple test to check this:
1. Create a string of 10 million characters.
2. Create a 2nd string that's the same 10 million characters plus an 'X'.
3. Create a 3rd string that's the same 10 million characters plus a 'Y'.
3. Perform isEqual: across the three strings.

If the length-first hypothesis is correct, it should be noticeably faster when the lengths differ, and noticeably slower when the lengths are the same. Any sufficiently large value would work, 10 million is just an example.

It seems to me that relying on the optimizations of a class's isEqual method is silly when there is a very clean way to test for an empty string.

The code:

Code:

if ([field.text length] == 0)

uses one of the primitive methods of the class directly to test that the string is empty. ANY other call you do (like isEqual or isEqualToString) at a minimum will have to call the length methods on both the field's text and the blank string you are passing in. If it is a naive implementation, it could be much, much worse.

Finally, checking that the length == 0 is really easy to read and maintain.