Иногда я нахожу код, который тестирует если два NSString
s являются тем же как это:
if ([str1 compare:str2] == NSOrderedSame) {
// Do something
}
Теперь, я полагаю, что это менее читаемо, чем использование isEqualToString:
и это также имеет некоторые противные побочные эффекты, как если str1 == nil
если (..) оценивает к истинному, или когда str2 == nil
опустошение могло бы повредиться на нас согласно документам Apple. (Редактирование: Поскольку hatfinch указывает, если str1 == nil && str2 == nil
оба варианта приводят к неправильному результату. Таким образом, необходимо охранять себя против этого случая так или иначе).
Но прежде чем я борюсь против тех операторов в моем коде компаний, я хотел удостовериться, что я не упускал некоторую важную суть.
Таким образом, мой вопрос в основном сводится к: Есть ли любое различие между a compare:
кому: NSOrderedSame
и isEqual:
?
Читая документацию, я могу обнаружить единственные различия, о которых вы еще не упомянули:
isEqualToString:
сначала сравнивает id
двух строки, что является потенциальным приростом скорости в приложении, которое часто повторно использует строки. Из ссылки на NSString:
Возвращаемое значение:
ДА, если aString эквивалентен получателю (если у них одинаковый идентификатор или если они являются NSOrderedSame в буквальном сравнении), в противном случае - НЕТ.
isEqualToString:
действительно более аналогичен compare: options: NSLiteralSearch
, как видно из приведенной выше цитаты. NSLiteralSearch более требователен к представлению символов Юникода:
«Литерал» в применении к сравнению строк означает, что различные правила декомпозиции Юникода не применяются и символы Юникода сравниваются индивидуально. Так, например, «Ö», представленное как составная последовательность символов «O» и умляут, не будет сравниваться как «Ö», представленное как один символ Unicode.
Это действительно просто придирка по сравнению с ложными срабатываниями и неопределенным поведением, упомянутыми в вашем вопросе.
Источник: Описание класса NSString