4

I saw a couple of questions here on SO, with ansers including the function isEqual: instead of the standard ==.

So far, I have only learned to use the ==, so I'm wondering what's better to use, what are the pros and cons of each? When should you use them?

Thank you.

Emil
  • 7,220
  • 17
  • 76
  • 135

2 Answers2

9

They do different things; so you need to use the appropriate one:

Consider, if you will:

NSString *a = @"Hello!";
NSString *b = a;
NSString *c = [a mutableCopy];

if (a == b) NSLog(@"This prints");
if (b == c) NSLog(@"This doesn't");
if ([a isEqual:c]) NSLog(@"This does");

In other words; == merely checks if two pointers point to the same place, and therefore are the same object; isEqual: checks if the two objects are equal; in this case a and b are the same string, while c is a new string that is equal to a, in that it has the same characters in the same order; but it has a different class and a different address.

You'll almost always want to use isEqual: for objects, and, if they have it, a more specific comparator if they are of the same class (isEqualToString:, for example).

== on the other hand you should probably only use for integer data types. (They make little sense for objects, and less for floating point numbers.)

Williham Totland
  • 28,471
  • 6
  • 52
  • 68
  • 2
    Careful, `[a copy]` may return the same object, because it is an immutable string. – dreamlax Sep 18 '10 at 10:25
  • dreamlax: True, answer updated for clarity; tho' I do believe copying an NSConstStr will yield an NSConcreteImmutableString; I might be wrong. – Williham Totland Sep 18 '10 at 11:10
  • 1
    @ Williham Totland: sending copy to a constant string just gives you the same pointer back. – JeremyP Sep 18 '10 at 12:36
  • So `isEqual` can be true (two identical objects) while `==` is false (point to the different places in memory where two identical objects are). On the other hand, if `==` is true, there is no way `isEqual` can be false? – Jakub Truhlář Sep 26 '16 at 10:25
  • @JakubTruhlář Not quite. If isEqual is implemented to return false for the same object, then it will. (Something like a SQLNull, for instance, could do that, giving `[[SQLNull sharedNull] isEqual:[SQLNull sharedNull]]` giving false, even if `[SQLNull sharedNull] == [SQLNull sharedNull]` is true, because in our putative `SQLNull` class, `- (BOOL)isEqual:(id)b { return NO; }` – Williham Totland Sep 26 '16 at 10:29
  • I was talking in general. Not when you force overriden `isEqual ` to return `false`. But beside that, the conclusion is true, do not you think? – Jakub Truhlář Sep 26 '16 at 10:42
  • @JakubTruhlář "Besides the case where it's false, it's true?" No. It's false. You don't know what `isEqual:` does, and you shouldn't need to, unless you've implemented the class yourself. Always compare objects using `isEqual:` (or more specific comparators). – Williham Totland Sep 26 '16 at 10:49
  • I was talking about pure value equality, but this is a good point. Thanks. – Jakub Truhlář Sep 26 '16 at 11:27
1

isEqual will compare objects according to the method written for the receiver object

== compares the addresses of Objects (or their values for C type variables like ints

This means for say NSStrings == compares the address but isEquals: will look at the values of the string objects and so does something similar to strcmp

Note that many strings are interned so that their addresses are the same if their data is the same so == can appear to work in test cases.

mmmmmm
  • 32,227
  • 27
  • 88
  • 117