• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: inconsistent behavior of NSString's localizedCaseInsensitiveCompare
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: inconsistent behavior of NSString's localizedCaseInsensitiveCompare


  • Subject: Re: inconsistent behavior of NSString's localizedCaseInsensitiveCompare
  • From: Jens Alfke <email@hidden>
  • Date: Sun, 06 May 2012 11:46:38 -0700

On May 5, 2012, at 10:06 PM, Quincey Morris wrote:

> However, even in pure ASCII strings, 'localizedCaseInsensitiveCompare:' doesn't support sorting via (say) a binary search. Strings such as "a" and "A" are *equal* according to this method. Binary search doesn't work if sorted elements are equal according to the comparison function.

I disagree. Binary search of a sorted array works fine if there are different keys that sort as equal; it’s just that it’ll find *one* of the equal keys, and you’d then have to look at its neighbors to find all the others. If you mean tree-based searching, that works fine too; for example, HFS+ stores the disk catalog as a b-tree and of course uses a case-insensitive comparison by default. (OK, HFS+ doesn’t allow multiple items with equivalent keys [paths], but there are b-tree storage libraries like Berkeley DB that do.)

> The NSString option that apparently causes this is 'NSForcedOrderingSearch', but the documentation doesn't really say whether this option is assumed by 'localizedCaseInsensitiveCompare:' or not. (The documentation for 'caseInsensitiveCompare:' implies not.)

The docs for NSForcedOrderingSearch read: "Comparisons are forced to return either NSOrderedAscending or NSOrderedDescending if the strings are equivalent but not strictly equal.” In other words, it only returns 0 if the strings are identical This is definitely not true of -caseInsensitiveCompare, localized or not.

In other words, if you want a stable case-insensitive sort (where equivalent strings always appear in a certain fixed order) you can’t just use -caseInsensitiveCompare:; you have to use one of the -compare: methods that takes options, and enable NSForcedOrderingSearch.

—Jens


_______________________________________________

Cocoa-dev mailing list (email@hidden)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:

This email sent to email@hidden


References: 
 >inconsistent behavior of NSString's localizedCaseInsensitiveCompare (From: Martin Wierschin <email@hidden>)
 >Re: inconsistent behavior of NSString's localizedCaseInsensitiveCompare (From: Quincey Morris <email@hidden>)
 >Re: inconsistent behavior of NSString's localizedCaseInsensitiveCompare (From: Martin Wierschin <email@hidden>)
 >Re: inconsistent behavior of NSString's localizedCaseInsensitiveCompare (From: Kyle Sluder <email@hidden>)
 >Re: inconsistent behavior of NSString's localizedCaseInsensitiveCompare (From: Jens Alfke <email@hidden>)
 >Re: inconsistent behavior of NSString's localizedCaseInsensitiveCompare (From: Quincey Morris <email@hidden>)

  • Prev by Date: Re: Issue when hiding NSTableColumn while resizing
  • Next by Date: Re: Can record ID in iOS address book database change
  • Previous by thread: Re: inconsistent behavior of NSString's localizedCaseInsensitiveCompare
  • Next by thread: Re: inconsistent behavior of NSString's localizedCaseInsensitiveCompare
  • Index(es):
    • Date
    • Thread