95 votes

NSString : isEqual vs. isEqualToString

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

Pourquoi les classes ajoutent-elles des méthodes isEqualTo* (isEqualToArray pour NSArray, isEqualToData pour NSData, ...) au lieu de se contenter d'une simple surcharge isEqual: ?

104voto

Abizern Points 52378

isEqual: compare une chaîne de caractères à un objet, et retournera NO si l'objet n'est pas une chaîne de caractères. isEqualToString: est plus rapide si l'on sait que les deux objets sont des chaînes de caractères, car la fonction documentation États :

Considérations particulières

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

isEqualTo<Class> est utilisé pour fournir des contrôles spécifiques de l'égalité. Par exemple ; isEqualToArray: vérifie que les tableaux contiennent un nombre égal d'objets, et que les objets à un index donné renvoient YES para el isEqual: test.

3 votes

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

2 votes

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

0 votes

16voto

Jonathan Dann Points 231

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

1 votes

Je n'avais jamais vu cela auparavant, y a-t-il de la documentation à votre connaissance ?

2 votes

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

9 votes

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

5voto

iKenndac Points 14855

Mon devinez est qu'elle offre une légère amélioration des performances, car isEqualToString : n'aura pas à vérifier le type de ce qui est transmis.

0 votes

Votre supposition est probablement vraie :)

5voto

respectTheCode Points 6453

En développant les réponses de @Abizern et @Jonathan Dann, les deux isEqual y isEqualToString travailler avec nil valeurs.

- (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");
}

4voto

Ben Packard Points 3441

Je recommande vivement este . Les avantages de isEqualToString en termes de performances sont fondamentalement négligeables pour la plupart des applications. Mais il y a deux autres distinctions que l'auteur mentionne :

  • Sécurité de type
  • La manière nil est traité

0 votes

Je ne vois pas de différence dans la façon dont nil est traité par les deux. Que le néant soit le récepteur ou l'argument ou les deux.

0 votes

Ce qui est "ceci" n'existe plus.

1 votes

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

Prograide.com

Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.

Powered by:

X