Чи слід використовувати uint в C # для значень, які не можуть бути від'ємними?

Я щойно спробував реалізувати клас, де uintзамість цього є численні властивості length / count тощо int. Однак, роблячи це, я помітив, що насправді боляче це робити, як ніби насправді ніхто цього не хоче робити.

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

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

PS: Я бачив це запитання, і це принаймні пояснює, чому сам фреймворк завжди використовує, intале навіть у власному коді насправді доволі uintважко дотримуватися, що змушує мене думати, що це, мабуть, насправді не потрібне.

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

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

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

Негативне значення часто використовується для сигналізації про стан помилки, і розмір операції часто повертається викликом функції; Отже, негативне значення може сигналізувати про помилку, не вдаючись до механізму виключення.

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

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

Використання int також корисно для виявлення цілочисельного переповнення в операціях.

IMO, недоліком використання 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);