Почему Array.Length int, а не uint [дубликат]

Почему Array.Lengthint, а не a uint. Это беспокоит меня (только немного), потому что значение длины никогда не может быть отрицательным.

Это также вынудило меня использовать int для свойства длины в моем собственном классе, потому что когда вы указываете int-значение, это должно быть приведено явно ...

Итак, главный вопрос: есть ли смысл для unsigned int ( uint)? Кажется, даже Microsoft не использует их.

8.08.2008 19:34:13
Несмотря на вопросы, поднятые ниже, я думаю, что это должно измениться на UInt.
alan2here 28.11.2011 23:43:24
@ alan2 здесь внесение такого изменения нарушит практически весь код, поэтому, если вы спросите меня, этого не произойдет!
Peter 23.08.2012 14:38:34
5 ОТВЕТОВ
РЕШЕНИЕ

Неподписанный int не совместим с CLS и поэтому будет ограничивать использование свойства теми языками, которые реализуют a UInt.

Посмотреть здесь:

Framework 1.1

Введение в библиотеку классов .NET Framework

Framework 2.0

Обзор библиотеки классов .NET Framework

60
10.05.2015 14:05:11

Как правило, целочисленные значения являются знаковыми, если вам явно не нужно значение без знака. Это просто, как они используются. Возможно, я не согласен с этим выбором, но это так.

В настоящее время, с сегодняшними типичными ограничениями памяти, если вашему массиву или подобной структуре данных требуется длина UInt32, вы должны рассмотреть другие структуры данных.

Int32 предоставит вам 2 ГБ значений с массивом байтов

-1
8.08.2008 19:40:31
"но это так, как оно есть". - нет, вещи никогда не бывают такими, какие они есть. Всегда принимается дизайнерское решение, и всегда стоит спросить, почему. Можно извлечь уроки из плюсов и минусов или привлечь дизайнера (в некоторых случаях) к обсуждению их. Всегда задавайте вопросы! :)
Jonas Kölker 25.06.2009 10:54:38

Я думаю, что это также может иметь отношение к упрощению вещей на более низком уровне, так как Array.Length, конечно, будет добавлен к отрицательному числу в некоторый момент, если Array.Length был беззнаковым, и добавлен к отрицательному int (дополнение к двум) Могут быть грязные результаты.

1
8.08.2008 20:05:07
Пожалуйста, приведите пример? uint lenght = 3;int x = -4;Console.WriteLine(x+lenght);дает -1 просто отлично.
Carlo V. Dango 12.06.2014 22:46:01

Похоже, никто не дал ответ на «окончательный вопрос».

Я полагаю, что основное использование неподписанных целочисленных объектов состоит в том, чтобы облегчить взаимодействие с внешними системами (P / Invoke и т. П.) И покрыть потребности различных языков, портируемых на .NET.

1
13.10.2008 15:23:42
Типы без знака необходимы при объединении нескольких меньших значений для получения большего. Можно объединить два UInt16 для создания UInt32 с помощью вычислений (HighPart << 16) + LowPart, а один можно разделить UInt32 на два UInt16 через (Uint16)(Value >> 16)и (Uint16)(Value & 65535). Такие операции были бы очень неудобными, если бы LowPartони были подписанного типа. При этом взаимодействие между типами со знаком и без знака часто бывает запутанным и проблематичным. Неподписанные типы во многом должны рассматриваться как их собственный мир.
supercat 3.02.2013 17:45:16

Много причин:

  • uint не соответствует CLS, поэтому создание зависимого от него встроенного типа (массива) было бы проблематичным
  • Среда выполнения в первоначальном виде запрещает любой объект в куче, занимающий более 2 ГБ памяти. Поскольку массив максимального размера, который был бы меньше или равен этому пределу, был бы новым байтом [int.MaxValue], людям было бы непонятно, чтобы иметь возможность генерировать положительную, но недопустимую длину массива.
  • Исторически C # наследует большую часть своего синтаксиса и соглашения от C и C ++. В этих массивах есть просто арифметика указателей, поэтому возможна отрицательная индексация массива (хотя обычно это неправильно и опасно). Поскольку существующий код предполагает, что индекс массива подписан, это было бы фактором
  • Относительно примечания: использование целых чисел со знаком для индексов массивов в C / C ++ означает, что взаимодействие с этими языками и неуправляемыми функциями в любом случае потребует использования int в этих условиях, что может привести к путанице из-за несоответствия.
  • Реализация BinarySearch (очень полезный компонент многих алгоритмов) полагается на возможность использовать отрицательный диапазон типа int, чтобы указать, что значение не было найдено, и местоположение, в котором такое значение должно быть вставлено для поддержания сортировки.
  • При работе с массивом вполне вероятно, что вы захотите принять отрицательное смещение существующего индекса. Если вы используете смещение, которое приведет вас к началу массива с использованием модуля, то поведение обтекания сделает ваш индекс, возможно, допустимым (в том смысле, что он положительный). С int результат будет недопустимым (но безопасным, поскольку среда выполнения защитит от чтения недопустимой памяти)
48
22.07.2015 11:33:52
Если размер кучи не может превышать 2 ГБ, то почти все массивы длины int.MaxValue являются недопустимыми, поскольку большинство типов имеют размер более 1 байта.
ScottS 29.01.2009 13:50:56
на самом деле, но ((uint) (int.MaxValue)) + 1 гарантированно неверно для чего-либо . int сам по себе далек от совершенства, но баланс вещей делает законным использование типа int.
ShuggyCoUk 29.01.2009 17:09:28
Начнем с явного типа ArrayIndex (по сути size_t), который будет переводить чисто и безопасно в int по мере необходимости, возможно, в будущем упростит использование по-настоящему, позволяя использовать массивы> 2 ГБ в будущем с меньшими трудностями. Но прагматики говорят, что у java такая же проблема, поэтому зачем рисковать
ShuggyCoUk 29.01.2009 17:13:42
Это очень информативно. В Windows Communication Foundation , а в .NET 4.0 - наибольшие значения были 2147483647 для maxArrayLengthи maxBytesPerReadкоторые ретроспективно делает много смысла с этой информацией. Соединяя точки ...
Derek W 1.02.2014 17:29:51
Просто хочу добавить, что арифметика указателя C # в небезопасных контекстах также допускает отрицательные индексы. Смотрите пример здесь: docs.microsoft.com/en-us/dotnet/csharp/language-reference/…
Mike Marynowski 16.10.2017 02:43:31