Почему CompareTo on short реализуется именно таким образом?
Рассмотрим следующий код:
namespace ConsoleApplication1 {
class Program
{
static void Main(string[] args)
{
Console.WriteLine(100.CompareTo(200)); // prints -1
Console.WriteLine(((decimal)100).CompareTo((decimal)200)); // prints -1
Console.WriteLine(((short)100).CompareTo((short)200)); // prints -100
Console.WriteLine(((float)100).CompareTo((float)200)); // prints -1
Console.ReadKey();
}
}
}
мой вопрос заключается в том, есть ли какие-либо конкретные причины, по которым CompareTo-метод на Int16 возвращает значения, отличные от -1, 0 и 1?
ILSpy показывает, что это реализовано таким образом
public int CompareTo(short value)
{
return (int)(this - value);
}
В то время как метод имплантирован в Int32 таким образом
public int CompareTo(int value)
{
if (this < value)
{
return -1;
}
if (this > value)
{
return 1;
}
return 0;
}
2 ответа:
Разница в том, что для
Другими словами, конкретная причина заключается в том, что вы можете получить ярлык сshort
нет никаких шансов на переполнение результата. Например,short.MinValue - (short) 1
все еще отрицательно, тогда какint.MinValue - 1
- этоint.MaxValue
.short
(без каламбура), тогда как тот же ярлык не работает сint
. Вы определенно не должны требоватьIComparable<T>.CompareTo
реализации для возврата -1, 0 или 1. Из документации довольно ясно, что результат имеет смысл только в терминах быть отрицательным, нулевым или положительным.
Ну, вы должны только действительно проверить знак в любом случае, но по причинам: я предполагаю, что для
Я бы предпочел, чтобы это было последовательно, но это не кажется проблемой. Скорее всего, это нетипичная оптимизация, но в рамках документированного API. В частности, оптимизацияint
и т. д. Был бы риск переполнения/обертывания (при обработке 2 чисел большой величины), которые перевернули бы знак, то есть он должен проверить операторы.short
здесь не кажется, что она собирается получить массивное Количество использования (I Использованиеshort
, но не все , как , Как я делаюint
).