Следует ли использовать uint в C # для значений, которые не могут быть отрицательными?

Я только что попытался реализовать класс, в котором uintвместо него используются многочисленные свойства длины / количества и т int. Д. Однако при этом я заметил, что это на самом деле болезненно, как будто никто на самом деле этого не хочет.

Почти все, что выдает целочисленный тип, возвращает int, поэтому требуется приведение типов в нескольких точках. Я хотел построить StringBufferс длиной буфера по умолчанию для одного из полей этого класса. Также требуется гипс.

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

PS: Я видел этот вопрос, и это, по крайней мере, объясняет, почему сам фреймворк всегда использует, intно даже в собственном коде его на самом деле громоздко придерживаться, uintчто заставляет меня думать, что он явно не нужен.

Хотя строго вы должны использовать uintдля переменных, которые содержат неотрицательное целое число, вы столкнулись с одной из причин, по которой это не всегда возможно.

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

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

Отрицательное значение часто используется для обозначения состояния ошибки, а размер операции часто возвращается при вызове функции; поэтому отрицательное значение может сигнализировать об ошибке, не прибегая к механизму исключения.

Также обратите внимание, что .NET часто строится на простых библиотеках C, поэтому разумно продолжить это соглашение. Если вам требуется большее пространство индекса, вы можете нарушить соглашение о другом механизме сигнализации об ошибках.

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

Использование int также полезно для обнаружения целочисленного переполнения в операциях.

ИМО, недостатком использования uintявляется то, что он скрывает условия ошибки. Эквиваленты следующего кода не так хороши:

if (len < 0)
    terminate_program("length attained impossible value.");

Конечно, ваши программы не должны ничего просчитывать с самого начала, но я считаю, что они также должны быть написаны для быстрого обнаружения числовых ошибок без распространения. В случае, когда MaxValue 2 ^ 31 достаточно, я говорю использовать intвместе с правильным использованием System.Diagnostics.Debug.Assert()и соответствующими проверками ошибок, как показано выше.

Если вы все же используете, uintиспользуйте его вместе с, checkedчтобы предотвратить переполнение и получить те же результаты. Однако я обнаружил, что проверку немного сложно применить к существующему коду, который для некоторых целей использует приведение типов.

Не плывите против течения, если в этом нет необходимости. Если не загромождать код приведениями, он становится более читабельным. Кроме того, если ваши возможные значения соответствуют int, то использование int не является проблемой.

Если вы боитесь, что вы можете переполнить int, то во что бы то ни стало ... но не оптимизируйте преждевременно.

Я бы сказал, что улучшенная читаемость минимизации приведений перевешивает немного повышенный риск ошибки при использовании int.

Если вы хотите проверить, что значение положительное, лучше, вероятно, просто использовать assert (обратите внимание, что это всего лишь метод отладки - вы должны убедиться, что этого никогда не произойдет в окончательном коде).

using System.Diagnostics;
...
Debug.Assert (i > 0);