CompareTo issue.

  • Thread starter Thread starter Guest
  • Start date Start date
G

Guest

I have a situtation where CompareTo is returning strange results when having
dashes in strings. The most concise illustration is:
"10050".CompareTo("1005-") = 1
"10050".CompareTo("1005-0") = -1
I have run alot more tests (I can post a short program if useful), but the
rule seems to be - < 0 at the end of a string but - = 0 in the middle of a
string.

Does anybody know what's going on here?
 
When comparing strings less than and greater than are very hard to define,
the important thing we need to look at is equality.
 
Hmm... Maybe you can explain what's so hard about sorting strings. In 25
years in computing I have never before encountered a system that couldn't
sort a list of strings. It's a pretty basic requirement in computing.

I'm trying to sort a list to use in a binary search, where the search key
does not have to be completely specified. Here's how the list I gave it
sorted (quotation marks are just to mark the beginning/end of the key.)
"1005-","10050","1005-0","100500","1005-00","1005-00
","100500 ","100501","1005-01",
"1005-01 ","100501 ","1005-1"
Given a key of "10050" you would hope to get "10050","100500","100500
". With this screwed up sort, however, the algorithm would terminate when
it it saw "1005-0" so neither "100500" and "100500 " would appear in
the result list.
 
You're right, actually i was not thinking from that perspective. Anyways i
dug through the BCL code and then through Rotor, i have finally found the
code that String class in .Net uses for string comparison. It is is
\Rotor\sscli\clr\src\classlibnative\nls\comnlsinfo.cpp , go through the code
in this method, it sheds a lot of light on the workings of string
comparison. I haven't had the time to go through the code in detail, but
from what i see there is significant algorithm variance based on case
sensitivity, are you using a case sensitive search?
 
Back
Top