за допомогою uint проти int [закрито]

Я деякий час спостерігав, що програмісти на C #, як правило, використовують int скрізь і рідко вдаються до uint. Але я ніколи не знайшов задовільної відповіді, чому.

Якщо ваша мета - взаємодія, uint не повинен з’являтися в загальнодоступних API, оскільки не всі мови CLI підтримують цілі числа без знака. Але це не пояснює, чому int так поширений, навіть у внутрішніх класах. Я підозрюю, що саме з цієї причини uint економно використовується в BCL.

У C ++, якщо у вас є ціле число, для якого від'ємні значення не мають сенсу, ви вибираєте ціле число без знака.

Це чітко означає, що від’ємні числа заборонені чи очікувані, і компілятор перевірить за вас. Я також підозрюю, що стосується індексів масивів, що JIT може легко скинути перевірку нижньої межі.

Однак при змішуванні типів int та unit потрібен додатковий догляд та зліпки.

Чи слід більше використовувати uint? Чому?

uintПідозрюю, основною причиною є ваше спостереження, чому в BCL не використовується.

UInt32 не відповідає CLS, а це означає, що він абсолютно непридатний для використання в загальнодоступних API. Якщо ви збираєтеся використовувати uint у своєму приватному API, це означатиме перетворення на інші типи - і, як правило, простіше і безпечніше просто зберегти тип незмінним.

Я також підозрюю, що це не так часто зустрічається у розробці C #, навіть коли C # є єдиною мовою, що використовується, насамперед тому, що вона не є поширеною в BCL. Загалом розробники намагаються (на щастя) імітувати стиль фреймворку, на якому вони будуються - у випадку C # це означає намагання зробити ваші API, загальнодоступними та внутрішніми, максимально схожими на .NET Framework BCL. Це означало б економно використовувати 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 <myname.length () типу речі) це просто стара звичка C - і коротша за типом, як згадувалося вище. Однак у деяких випадках, коли взаємодіє апаратне забезпечення, де я маю справу з прапорами подій з пристроїв, uint є важливим у випадках, коли прапор може використовувати лівий (найвищий) біт.

Чесно кажучи, за 99,9% моєї роботи я міг би легко використовувати ushort, але це, знаєте, звучить набагато краще, ніж ushort.

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

UINT дуже корисний і дурно говорити інакше. Якщо хтось думає лише тому, що йому ніколи не потрібно було використовувати uint, ніхто інший цього не зробить, ви помиляєтесь.

Я думаю, що це просто лінь. C # за своєю суттю є вибором для розробки на настільних ПК та інших машинах із відносно великими ресурсами.

Однак C і C ++ мають глибоке коріння у старих системах та вбудованих системах, де пам'ять обмежена, тому програмісти використовуються для ретельного продумування типу даних. Програмісти на C # ледачі, і оскільки ресурсів загалом достатньо, ніхто насправді не оптимізує використання пам'яті (загалом, звичайно, не завжди). Подія, якщо байту було б достатньо, багато програмістів C #, включаючи мене, просто використовують int для простоти. Більше того, багато функцій API приймають ints, тому це запобігає трансляції.

Я погоджуюсь, що вибір правильного типу даних - це хороша практика, але я думаю, що головною мотивацією є лінь.

Нарешті, вибір цілого числа є математично правильнішим. Непідписані ints в математиці не існують (лише натуральні числа). І оскільки більшість програмістів мають математичний досвід, використання цілого числа є більш природним.

Я думаю, що велика частина причини полягає в тому, що коли C вперше вийшов, більшість прикладів використовувались intдля стислості. Ми раділи тому, integerщо нам не доводилось писати так, як писали з Фортраном та Паскалем, і в ті часи ми регулярно використовували їх для повсякденних речей, таких як індекси масивів та лічильники циклів. Беззнакові цілі числа були особливими випадками для великих чисел, яким потрібен останній додатковий біт. Я думаю, що це природна прогресія того, що звички C продовжували існувати на C # та інших нових мовах, таких як Python.

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

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

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

Я знаю, що це, мабуть, стара тема, але я хотів дати кілька пояснень.

Давайте візьмемо int8, який ви можете зберегти від –128 до 127, і він використовує 1 байт, що становить 127 позитивних чисел.
Коли ви використовуєте int8, один із бітів використовується для від'ємних чисел -128.
Коли ви використовуєте Uint8, ви даєте від’ємні числа позитивним, тому це дозволяє використовувати 255 позитивних чисел з однаковим об’ємом зберігання 1 байт.
Єдиний результат - це те, що ви втратили можливість використовувати негативні значення.
Ще однією проблемою цього є не всі мови програмування, і бази даних це підтримують.
На мою думку, єдиною причиною, по якій ви б це використовували, є те, що вам потрібно бути ефективним, як-от ігрове програмування, і вам потрібно зберігати великі невід’ємні числа. Ось чому не так багато програм використовують це.

Основна причина полягає в тому, що сховище не є проблемою, і ви не можете гнучко використовувати його з іншим програмним забезпеченням, плагінами, базою даних або Api. Також, наприклад, банку знадобляться від'ємні числа для зберігання грошей тощо.

Сподіваюся, це комусь допоможе.