Почему для счётчиков не используют беззнаковые (unsigned) числа?

Question

[Kirgus]

Часто вижу в коде на C++ и C#, что для счётчиков (а для большинства счётчиков используются только натуральные числа, ну и иногда ещё ноль) используют int, а не uint/unsigned int. В итоге максимальное значение счётчика в таком коде уменьшается вдвое. Почему праграмисты делают это? Может быть это из-за плохой совместимости между int и uint? Что, по вашему мнению, правильнее выбрать?

Comments

[Griboks]

Поставьте, пожалуйста, теги языков программирования, а то придется призывать модератора.

[WbICHA]

В 99.9999% случаев ты даже к половине половины максимального значения не приблизишься и близко, так зачем забивать этим голову?
А случаи, где приблизишься, вопрос о типе счётчика будет самой наименьшей твоей проблемой.

[Kirgus]

Griboks, так они стояли О_о

Answer 1

[Василий Банников]

В целом - так исторически сложилось, что в C# используется знаковый тип для индексации массивов.
В Java вообще, например, нет беззнаковых типов. (думаю, из-за этого и в C# для индексации используется int)
В новых языках, например в Rust от этого сразу уходят - в нём для индексации массивов используется usize (беззнаковый, размером с указатель на целевой машине)

Answer 2

[Александр Скуснов]

Смотрите фокус. Такой код выполняется:

unsigned int i = 0, N = 5;
	
	while (i < N) {
		std::cout << i << "\n";
		++i;
	}

А в таком стиле нет:

unsigned int i = 0, N = 5;
	
	while (i - N < 0) {
		std::cout << i << "\n";
		++i;
	}

Дело в том, что умный компилятор понял, что арифметическая операция с беззнаковыми числами всегда неотрицательна, и просто выкинул ваш цикл как бесполезный. Так что лучше использовать знаковые счётчики.
UPDATE
Точнее, может, он и не выкидывает, но разница это беззнаковое число, поэтому больше нуля ,поэтому первая итерация цикла не выполняется и цикл заканчивается.

Comments

[Kirgus]

Интересный пример) Спасибо

Answer 3

[Adamos]

У std::vector как раз не int, а size_t, который алиас для unsigned long.
В результате строгий компилятор на действия индексной арифметики, где, внезапно, вполне могут использоваться отрицательные числа, сыплет предупреждениями о том, что вместо беззнакового числа получается знаковое, ай-яй-яй. И оно с одной стороны правильно, потому что отрицательных индексов, скорее всего, не предполагается и тут могут крыться ошибки, а с другой - ну что программист с этим сделает? Приведет к беззнаковому и вместо одной ошибки спровоцирует другую?

Comments

[Армянское Радио]

Приводя к беззнаковому, хорошо вышколенный программист поставит assert( i >= 0 ) и покроет это место тестами на три слоя.

[Adamos]

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

Answer 4

[Griboks]

Потому что длина массива имеет тип int. Счетчик, который нужен для итераций по массиву, даже теоретически не можетппреполниться, потому что всегда будет не более n-1, где n:int.

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

Comments

[Kirgus]

А как же C++?

[Griboks]

Кирилл Гусарев, в c++ индекс массива может быть отрицательным (a[b] == a+b), поэтому смысла использовать unsigned int мало. С другой стороны, при аллокации массива его длина задается любым int, но оно должно быть больше нуля. В итоге получается 50 на 50. Тут, на мой взгляд, исторически сложилось использовать int, т. к. он чаще используется.

[Griboks]

Кирилл Гусарев, p. s. надо понимать, что исторически сложилась некая общая практика (best practice), которая затем перешла в дизайн языков, на форумы и в официальные документации.

[Kirgus]

Griboks, спасибо

[Армянское Радио]

Griboks, вы заблуждаетесь. В C++ размер массива и тип аргумента у оператора [] - size_t. Который всегда - беззнаковое целое такого размера, чтобы им можно было индексировать всю оперативку на данной архитектуре - так в Стандарте языка написано.

[Griboks]

Армянское Радио, в спецификации (она старая, новую c++20 бесплатно не раздают) написано, что этт может быть любое целое число или перечисление. При инициализации оно должно быть положительным, при индексации - любым.

[jcmvbkbc]

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

Армянское Радио, подскажите место в стандарте, где это написано?

[Армянское Радио]

jcmvbkbc, Если цепляться к запятым, там написано что-то вроде "размер самого большого объекта, включая массив". Потому что size_t - это результат встроенного sizeof()

size_t is the unsigned integer type of the result of the sizeof operator (ISO C99 Section 7.17.)

[Griboks]

Армянское Радио, у вас есть ссылка? Потому что поверить, что раньше индекс мог быть отрицательным, а теперь вдруг это запретили, довольно сложно. Тем более, что тогда делать с a[0]?

[Армянское Радио]

Griboks, отрицательный индекс в C/С++ никогда бы не работал, потому что элементы массива индексируются 0..N-1. Любой индекс вне этого диапазона, а значит и отрицательный - это UB.

[Griboks]

Армянское Радио, прекрасно работал. Никто не просит вас брать - 1 элемент, но вы всегда можете взять N-1-i элемент, если будете применять отрицательный индекс к хвосту массива, а не к голове. Кроме того существую еще и многомерные массивы, которые, насколько я помню, есть ничто иное как массив массивов, поэтому вы можете обращаться к i и i-N элементам сразу.

[Армянское Радио]

Griboks, Это не будет отрицательным индексом. Индекс у массива - это то, что в конечном итоге передается в оператор [].

[jcmvbkbc]

Если цепляться к запятым

Армянское Радио, это не "цепляться к запятым". "размер самого большого объекта" -- это свойство не столько архитектуры, сколько конкретной реализации тулчейна. Пожалуйста, не нужно говорить от имени стандарта того, чего в нём нет.

[Армянское Радио]

jcmvbkbc, спасибо за ценное замечание!

[Griboks]

Армянское Радио,первая ссылка в гугле

int a[3] = { 1, 2, 3 };
int* p = &a[1];  // Make p point to the second element

std::cout << p[-1];  // Prints the first element of a, equal to *(p - 1)
std::cout << p[ 0];  // Prints the second element of a, equal to *p
std::cout << p[ 1];  // Prints the third element of a, equal to *(p + 1)

+------+------+------+
| a[0] | a[1] | a[2] |
+------+------+------+
^      ^      ^
|      |      |
p-1    p      p+1

[Griboks]

Армянское Радио, в любом случае, в старом стандарте предусмотрены отрицательные индексы. Поэтому я не могу вам поверить без ссылки, что новый стандарт оборвал совместимость.

[Армянское Радио]

Griboks, Все хорошо, за исключением того, что p - не массив, а указатель

[jcmvbkbc]

отрицательный индекс в C/С++ никогда бы не работал, потому что элементы массива индексируются 0..N-1.

Армянское Радио, внезапно, индексировать можно не только массивы, но и указатели, а указатель легко может указывать в середину массива.

0..N-1. Любой индекс вне этого диапазона, а значит и отрицательный - это UB.

Это неправда. Стандарты, что С, что С++, разрешают индексам быть отрицательными, вычисление адресов и разыменование не вызывают UB пока адреса находятся в пределах объектов или массивов объектов.

[Армянское Радио]

jcmvbkbc, Я под массивом понимаю std::vector или std::array, а вы?

[jcmvbkbc]

Я под массивом понимаю std::vector или std::array

Армянское Радио, а зачем, если у массива (array) есть определение в стандарте, например такое?

[Griboks]

Армянское Радио, вы, видимо, ошиблись темой. Мы тут обсуждаем, что отрицательная индексация исторически встречалась чаще сверхбольших индексов в итерациях циклов, поэтому прижился тип int для счетчика (+другие операции с int) .

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

Answer 5

[mlyamasov]

Преимущества у беззнаковых счётчиков определённо есть: https://graphitemaster.github.io/aau/

Answer 6

[jcmvbkbc]

Часто вижу в коде на C++ и C#, что для счётчиков … используют int, а не uint/unsigned int.
Почему праграмисты делают это?

Я слышал следующую теорию, почему это имеет смысл в С++: потому что значение знакового типа в корректно написанном коде не переполняется. (А если таки случилось переполнение, то это UB и всё уже не важно). Поэтому если счётчик имеет знаковый тип и с ним на каждой итерации происходит, например, инкремент, то значение счётчика только увеличивается. Это, в свою очередь, даёт дополнительные возможности для оптимизации. Беззнаковый счётчик инкрементируемый на каждой итерации может внезапно обнулиться, это может быть легальным поведением программы на которое рассчитывает программист.

А почему они фактически используют int -- наверняка потому что никакой практической разницы не видно, а буков нужно меньше.

Comments

[Василий Банников]

а буков нужно меньше.

Ага, например в C#, если напишешь:
var i = 42, то i будет типа int
Чтобы получить uint - придётся ещё суффикс добавить

[Армянское Радио]

Разница очень быстро наступает и ломает код, когда дело доходит до обработки данных размером больше 2Гб. Что в современной практике далеко не редкость.

Answer 7

[mayton2019]

По поводу Java int.

Java создавалась до 1996 года. Это было абсолютное царство 32х разрядных машин. Даже первые Pentium адресовали мало. И никто не думал о том что когда-то разрядная сетка адреса будет удвоена. Тем более что основная целевая архитектура для JVM была микроволновками, кофеварками пультами ДУ и банковскими карточками. Поэтому выбор индекса массива в 32 бита со знаком был норм. Представте что всю память 4G занимает массив целых чисел. И в этом случае достаточно максимального индекса элемента равного 1 073 741 823, больше нет смысла.

По поводу беззнаковости. На битовых операциях signed int ведет себя также как и беззнаковый. Это декларировано на уровне стандарта JVM. Лишь только два логических сдвига различают знаковый бит.

Хотя скажу честно что для меня до сих пор странно иметь компаратор который неверно работает при переполнениях. Конечно хотелось в JVM иметь семантику uint, ulong e.t.c. Есть много величин которые принципиально неотрицательные. Время. Вес. И прочие величины из физики.

Comments

[jcmvbkbc]

до 1996 года. Это было абсолютное царство 32х разрядных машин. Даже первые Pentium адресовали мало. И никто не думал о том что когда-то разрядная сетка адреса будет удвоена.

"Здравствуйте", как бы говорит нам 64-битная DEC Alpha из 1992 года, на которой работала windows NT и куча всяких юниксов, "неуж-то таки никто не думал"?

[mayton2019]

jcmvbkbc, я-ж говорю. Кофеварки. Никто не думал что этот проект уйдет из мира прошивок в мир большого ентерпрайза. Кстати если вы изучали калькулятор МК-60 - то найдете общее с JVM.

[Василий Банников]

mayton2019,

Никто не думал что этот проект уйдет из мира прошивок в мир большого ентерпрайза.

Java же наоборот изначально на enterprise напирала, тк повышала надёжность ПО и снижала порог вхождения, по сравнению с тем же C++, который был тогда популярен для этого.
Тот же IBM WebSphere всего спустя 2 года вышел - в 1998, и Java EE тоже рядом

[mayton2019]

Василий Банников, я думаю что это замечательный пример адаптиции jvm под новые сферы.