To wymóg dla każdegorodzaj porównania działać tak, jak działa operator bazowyprzechodni iantysymetryczny.

W .NET to nie jest prawda dla niektórych ciągów:

static void CompareBug()
{
  string x = "\u002D\u30A2";  // or just "-ア" if charset allows
  string y = "\u3042";        // or just "あ" if charset allows

  Console.WriteLine(x.CompareTo(y));  // positive one
  Console.WriteLine(y.CompareTo(x));  // positive one
  Console.WriteLine(StringComparer.InvariantCulture.Compare(x, y));  // positive one
  Console.WriteLine(StringComparer.InvariantCulture.Compare(y, x));  // positive one

  var ja = StringComparer.Create(new CultureInfo("ja-JP", false), false);
  Console.WriteLine(ja.Compare(x, y));  // positive one
  Console.WriteLine(ja.Compare(y, x));  // positive one
}

Widzisz tox jest ściśle większa niży, iy jest ściśle większa niżx.

Box.CompareTo(x) i tak dalej wszystko daje zero (0), jasne jest, że nie jest to zamówienie. Nic dziwnego, że otrzymuję nieprzewidywalne wynikiSort tablice lub listy zawierające łańcuchy takie jakx iy. Chociaż tego nie testowałem, jestem pewienSortedDictionary<string, WhatEver> będzie miał problemy z utrzymaniem się w posortowanym porządku i / lub lokalizowaniem elementów, jeśli takie łańcuchy są podobnex iy są używane do kluczy.

Czy ten błąd jest dobrze znany? Które wersje struktury mają wpływ (próbuję tego z .NET 4.0)?

EDYTOWAĆ:

Oto przykład, w którym znak jest negatywny:

x = "\u4E00\u30A0";         // equiv: "一゠"
y = "\u4E00\u002D\u0041";   // equiv: "一-A"