использование uint vs int [закрыто]



Я наблюдал некоторое время, что программисты C#, как правило, используют int везде, и редко прибегают к uint. Но я так и не нашел удовлетворительного ответа на этот вопрос.



Если ваша цель-взаимодействие, uint не должен появляться в общедоступных API, потому что не все языки CLI поддерживают целые числа без знака. Но это не объясняет, почему int настолько распространен, даже во внутренних классах. Я подозреваю, что именно по этой причине uint используется экономно в BCL.



В C++, если у вас есть целое число, для которого отрицательные значения не имеют смысла, вы выбираете целое число без знака.



Это явно означает, что отрицательные числа не допускаются или ожидаются, и компилятор сделает некоторую проверку для вас. Я также подозреваю, что в случае индексов массива JIT может легко отбросить проверку нижних границ.



однако, смешивая типы Инт и блока, дополнительные забота и бросания будут необходимы.



должен ли uint использоваться больше? Зачем?

338   11  
c#

11 ответов:

ваше замечание о том, почему uint не используется в BCL является основной причиной, я подозреваю.

UInt32 не соответствует CLS, что означает, что он полностью не подходит для использования в общедоступных API. Если вы собираетесь использовать uint в своем частном API, это будет означать выполнение преобразований в другие типы - и, как правило, проще и безопаснее просто сохранить тип таким же.

Я также подозреваю, что это не так часто встречается в разработке C#, даже если C# является единственным языком используется, прежде всего, потому, что он не распространен в BCL. Разработчики, как правило, пытаются (к счастью) имитировать стиль фреймворка, на котором они строят - в случае C#это означает, что вы пытаетесь сделать свои API, общедоступные и внутренние, максимально похожими на BCL .NET Framework. Это означало бы использование uint экономно.

int короче, чтобы типа uint.

обычно int хватит. Если вы можете выполнить все следующие условия, вы можете использовать uint:

  • это не для публичного API (так как uint не соответствует CLS).
  • вам не нужны отрицательные числа.
  • вам (возможно) понадобится дополнительный диапазон.
  • вы не используя его в сравнении с < 0, а именно не true.
  • вы не используя его в сравнение с >= 0, а именно не false.

последнее требование часто забывается и вводит ошибки:

static void Main(string[] args)
{
    if (args.Length == 0) return;
    uint last = (uint)(args.Length - 1);

    // This will eventually throw an IndexOutOfRangeException:
    for (uint i = last; i >= 0; i--)
    {
        Console.WriteLine(args[i]);
    }
}

1) плохая привычка. Серьезно. Даже в C / C++.

подумайте об общем for шаблон:

for( int i=0; i<3; i++ )
    foo(i);

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

2) int воспринимается как родной тип машины.

предпочитаю uint до int если отрицательное число не находится в диапазоне допустимых значений. В частности, принимая int парам, но бросив ArgumentException если число меньше нуля просто глупо-используйте uint!

Я согласен, что uint используется недостаточно, и я призываю всех остальных использовать его больше.

я программирую на более низком уровне прикладного уровня, где ints редко получают выше 100, поэтому отрицательные значения не являются проблемой (например, для i

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

Я сделал оболочку Direct3D 10 В C# & нужно использовать uint, если я хочу создать очень большие буферы вершин. Большие буферы в видеокарте не могут быть представлены с подписанным int.

UINT очень полезно и глупо говорить иначе. Если кто-то думает только потому, что им никогда не нужно было использовать uint никто другой не будет, вы ошибаетесь.

Я думаю, что это просто лень. C# по своей сути является выбором для разработки на настольных компьютерах и других машинах с относительно большими ресурсами.

C и C++, однако, имеет глубокие корни в старых системах и встроенных системах, где память разрежена, поэтому программисты привыкли тщательно продумывать, какой тип данных использовать. Программисты на C# ленивы, и поскольку ресурсов в целом достаточно, никто не оптимизирует использование памяти (в общем, не всегда, конечно). Если байт будет достаточно, многие программисты на C#, включая меня, просто используют int для простоты. Кроме того, многие функции API принимают ints, поэтому он предотвращает литье.

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

наконец, выбор целого числа является более математически правильным. Беззнаковых целых чисел нет в математике (только натуральные числа). И поскольку большинство программистов имеют математический фон, использование целого числа больше природный.

Я думаю, что большая часть причины в том, что когда C впервые вышел большинство примеров, используемых int для краткости. Мы радовались, что не надо писать integer как мы делали с Fortran и Pascal, и в те дни мы обычно использовали их для мирских вещей, таких как индексы массивов и счетчики циклов. Целые числа без знака были частными случаями для больших чисел, которые нуждались в этом последнем дополнительном бите. Я думаю, что это естественная прогрессия, что привычки C продолжались в C# и других новых языках, таких как Python.

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

другие языки (например, C) рассматривают N-разрядные беззнаковые типы как группу, которая обертывается по модулю 2^N. обратите внимание, что вычитание N из члена такой группы не представляет собой численное вычитание, а скорее дает член группы, который, когда N добавляется к нему, даст оригинал. Возможно, некоторые операции, связанные со смесью подписанных и неподписанных значений, на самом деле не имеют смысла и, возможно, должны были быть запрещены, но даже код, который небрежен с его спецификациями таких вещей, как числовые литералы, обычно будет работать, и код был написан, который смешивает подписанные и неподписанные типы и, несмотря на небрежность, работает, что спецификация не склонна меняться в ближайшее время.

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

Я знаю, что это, вероятно, старая нить, но я хотел бы дать некоторые разъяснения.

давайте возьмем int8, который вы можете хранить от -128 до 127, и он использует 1 байт, что составляет в общей сложности 127 положительных чисел.
При использовании int8 один из битов используется для отрицательных чисел -128.
Когда вы используете Uint8, вы даете отрицательные числа положительным, поэтому это позволяет использовать 255 положительных чисел с одинаковым объемом памяти 1 байт.
Единственный недостаток-это ты теперь потеряли возможность использовать отрицательные значения.
Еще одна проблема заключается в том, что не все языки программирования и базы данных поддерживают это.
Единственная причина, по которой вы будете использовать это, на мой взгляд, - это когда вам нужно быть эффективным в игровом программировании, и вам нужно хранить большие неотрицательные числа. Вот почему не многие программы используют это.

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

Я надеюсь, это поможет кому-то.

Comments

    Ничего не найдено.