NSString: isEqual contre isEqualToString

94

Quelle est la différence entre isEqual:et isEqualToString:?

Pourquoi les classes ajoutent-elles des méthodes isEqualTo * (isEqualToArray pour NSArray, isEqualToData pour NSData, ...) au lieu de simplement remplacer isEqual:?

— Jaka Jančar
source

103

isEqual:compare une chaîne à un objet et retournera NOsi l'objet n'est pas une chaîne. isEqualToString:est plus rapide si vous savez que les deux objets sont des chaînes, comme l' indique la documentation :

Considérations particulières

Lorsque vous savez que les deux objets sont des chaînes, cette méthode est un moyen plus rapide de vérifier l'égalité que isEqual:.

isEqualTo<Class>est utilisé pour fournir des contrôles spécifiques d'égalité. Par exemple; isEqualToArray:vérifie que les tableaux contiennent un nombre égal d'objets et que les objets à un index donné retournent YESpour le isEqual:test.

— Abizern
source

3

Si vous croyez Aaron Hillegass, alors il n'y a pas de différence de performance, seulement un peu de sécurité de type: blog.bignerdranch.com/334-isequal-vs-isequaltostring

— Caro

2

Merci pour le lien - utile. Bien que vous nous demandiez de croire Mark Dalrymple - qui je fais :)

— Abizern

Lien mis à jour: bignerdranch.com/blog/isequal-vs-isequaltostring

— Max

16

Aussi, pour écrire vos propres méthodes -isEqual:et -isEqualTo<Class>:, la convention est d'autoriser nil arguments pour -isEqual:et de lever une exception pour les arguments nil à-isEqualTo<Class>:

— Jonathan Dann
source

1

Je n'avais jamais rencontré cela auparavant, aucune documentation à votre connaissance?

— Mike Abdullah

2

Cela ne semble pas être vrai pour isEqualToString, qui renvoie simplement NO si vous passez nil.

— Jaka Jančar

9

Intéressant, il est documenté dans la section Comparaison d'objets du <a href=" developer.apple.com/documentation/Cocoa/Conceptual/... Fundamentals Guide</a>

— Jonathan Dann

Ce n'est pas vrai. isEqualToString ne lève pas d'exception.

— respectTheCode

1

La page Web du Cocoa Fundamentals Guide indique: "Ce document ne représente peut-être pas les meilleures pratiques pour le développement actuel." C'est vieux, apparemment.

— cbh2000

5

Je suppose que cela fournit une légère amélioration des performances, comme isEqualToString: vous n'aurez pas à taper ce qui est passé.

— iKenndac
source

Votre supposition est probablement vraie :)

— Philip007

5

Développer les réponses @Abizern et @Jonathan Dann, les deux isEqualet isEqualToStringtravailler avec des nilvaleurs.

- (void)testStringEqual {
    NSString *string = nil;

    STAssertFalse([string isEqual:@"test"], @"NSString isEqual");
    STAssertFalse([string isEqualToString:@"test"], @"NSString isEqualToString");

    // Note that these both return NO
    STAssertFalse([string isEqual:nil], @"NSString isEqual");
    STAssertFalse([string isEqualToString:nil], @"NSString isEqualToString");

    string = @"test";

    STAssertTrue([string isEqual:@"test"], @"NSString isEqual");
    STAssertTrue([string isEqualToString:@"test"], @"NSString isEqualToString");

    STAssertFalse([string isEqual:nil], @"NSString isEqual");
    STAssertFalse([string isEqualToString:nil], @"NSString isEqualToString");
}

— respectTheCode
source

4

Je recommande fortement ce . Les avantages de performance de isEqualToString sont fondamentalement négligeables pour la plupart des applications. Mais il y a deux autres distinctions que l'auteur mentionne:

Sécurité de type
Le chemin nilest géré

— Ben Packard
source

Je ne vois aucune différence dans la manière dont nul est traité par les deux. Soyez nul comme receveur ou argument ou les deux.

— SayeedHussain

Tout ce que "ceci" n'existe plus: /

— Jared Grubb

1

Merci @JaredGrubb, j'ai trouvé la nouvelle URL.

— Ben Packard