Беззнаковые и подписанные числа в качестве индексов - PullRequest
8 голосов
/ 17 июня 2010

Каково обоснование использования чисел со знаком в качестве индексов в .Net?

В Python вы можете индексировать с конца массива, отправляя отрицательные числа, но в .Net это не так. Для .Net нелегко добавить такую ​​функцию позже, так как это может нарушить другой код, возможно, с использованием специальных правил (да, это плохая идея, но я предполагаю, что это происходит) при индексации.

Не то чтобы мне когда-либо приходилось индексировать массивы размером более 2 147 483 647, но я действительно не могу понять, почему они выбирают числа со знаком.

Может ли это быть потому, что в коде более нормально использовать числа со знаком?

Редактировать: Я только что нашел эти ссылки:

Опасности итерации без знака в C / C ++

Длина и индексы подписанных слов

Edit2: Хорошо, пара других веских причин из ветки Мэтью Флешен написал:

  • Исторические причины как язык, похожий на c
  • Взаимодействие с C

Ответы [ 4 ]

4 голосов
/ 17 июня 2010

Возможно, существует давняя традиция использования значения ниже 0 в качестве недопустимого индекса.Методы типа String.IndexOf возвращают -1, если элемент не найден.Следовательно, возвращаемое значение должно быть подписано.Если потребителям индекса потребуются значения без знака, вам придется a) проверить и b) привести значение, чтобы использовать его.С подписанными индексами вам просто нужен чек.

3 голосов
/ 17 июня 2010

Для простоты конечно. Вам нравится проблема делать арифметику размера с беззнаковыми числами?

2 голосов
/ 17 июня 2010

Без подписи не соответствует CLS.

0 голосов
/ 10 июля 2012

Основная полезность чисел без знака возникает при составлении больших чисел из меньших и наоборот. Например, если один получает четыре неподписанных байта от соединения и хочет рассматривать их значение, взятое в целом, как 32-разрядное целое число, использование типов без знака означает, что можно просто сказать:

  value = byte0 | (byte1*256) | (byte2*65536) | (byte3*16777216);

В отличие от этого, если бы байты были подписаны, выражение, подобное приведенному выше, было бы более сложным.

Я не уверен, что действительно вижу какую-либо причину для языка, разработанного в настоящее время, чтобы не включать неподписанные версии всех типов короче, чем самый длинный целочисленный тип со знаком, с семантикой, которая является целой (т.е. Любые операции определенного типа), которые будут полностью соответствовать наибольшему типу со знаком, будут по умолчанию выполняться , как если бы они работали с этим типом. Включение неподписанной версии самого большого подписанного типа усложнит языковую спецификацию (поскольку нужно будет указать, какие операции должны соответствовать диапазону подписанного типа, а какие операции должны соответствовать диапазону неподписанного типа), но в противном случае должно быть Нет проблем при разработке языка, чтобы if (unsigned1 - unsigned2 > unsigned3) давал «численно-корректный» результат, даже если unsigned2 больше unsigned1 [если кто-то хочет получить обход без знака, можно явно указать if ((Uint32)(unsigned1 - unsigned2) > unsigned3)]. Язык, который определяет такое поведение, безусловно, будет большим улучшением по сравнению с беспорядком, который существует в C (оправдано, учитывая его историю), C # или vb.net.

...