Что использовать, size_t или int в цикле for?

Question

[Имя]

Все используют int в подсчёте итераций цикла, а сейчас прочёл о том что это делает программу несовместимой с x64 архитектурой при обработке больших массивов и что лучше использовать size_t. Это верно?

Comments

[Roman]

https://en.cppreference.com/w/cpp/container
https://en.cppreference.com/w/cpp/iterator
https://en.cppreference.com/w/cpp/algorithm

Answer 1

[longclaps]

У вас большие массивы? Очень-очень?
Не забивайте себе голову фигнёй. Int - это нормально.

Answer 2

[tsarevfs]

Используйте решения в следующем приоритете:
1. готовый stl algorithm (например std::find, std::remove_if,...)
2. range based for "for (const auto& elem : myArray)"
3. for (auto iter = myArray.begin()...
4. int
5. size_t

Основная проблема с int -- раздражающий варнинг про сравнение знаковых и беззнаковых типов в
i < array.size(). Немного поможет std::ssize из C++20, который возвращает int. Массивы размера больше чем int встречаются слишком редко чтобы выбирать решение по умолчанию основываясь на них.

Беззнаковые типы приводят к куче ошибок связаных с отрицательными числами. В идеале их нужно использовать только там где нужны контролируемые переполнения (операции по модулю 2^{32,64}). Простой пример где можно выстрелить себе в ногу это цикл от 10 до 0.

Answer 3

[Melkij]

Выбирайте тот тип данных, который вам действительно нужен.
Если у вас в цикле пара миллионов итераций максимум - то зачем вам 64-битное целое?
Если же вам действительно мало 32-битного числа - то вы не можете использовать ни int ни size_t для этих целей, вы должны использовать именно 64-битное целое независимое от платформы.
А если у вас пара десятков итераций в прыжке - то вам и int слишком большой, возьмите что-нибудь поменьше.

Разным задачам нужны разные типы данных.

Comments

[Евгений Шатунов]

Melkij

Если же вам действительно мало 32-битного числа - то вы не можете использовать ни int ни size_t для этих целей, вы должны использовать именно 64-битное целое независимое от платформы.

А можно поподробнее почему в описанном случае нельзя использовать size_t? Желательно со ссылками на документацию и стандарт языка.

[Melkij]

Евгений Шатунов, потому что size_t - implementation-defined (гарантируется емнип вообще только 16 бит). Если вам заведомо необходимо 64-битное целое - то вам не по пути с implementation-defined вещами, вам нужно именно 64-битное целое.

[Евгений Шатунов]

Melkij , а где ссылки на документацию и стандарт?

[Melkij]

Евгений Шатунов, вы написали "желательно".
Хотите сказать, что я заблуждаюсь, и size_t даже на 32-битных платформах гарантированно 64-битный?

[sddvxd]

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

ниже int нет смысла ставить, поскольку с ним работает быстрее всего

[res2001]

Melkij, Если речь идет об итерациях по памяти (в массиве данных), то на 32 битных платформах не зачем иметь 64 битный счетчик, т.к. памяти физически не хватит для адресации второй половины индексов в 64 битном счетчике.
Поэтому в x32 платформах size_t 32 битный, а в x64 - 64-битный, т.е. выбраны оптимальные размеры счетчика для каждой платформы. size_t позволяет адресовать максимально возможное количество данных для конкретной платформы, об этом сказано в стандарте.
Кроме того, использовать знаковый тип для индексации элементов массива - ну это так себе идея - индексы обычно положительные, поэтому используя int мы теряем 1 бит в счетчике (а это половина всех возможных значений счетчика).

Счетчик в цикле не обязательно используется как индекс в массиве, так что всегда надо смотреть на ситуацию. Иногда действительно необходимо использовать uint64_t под счетчик, а иногда и uint8_t достаточно.

[Melkij]

res2001,

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

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

[Евгений Шатунов]

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

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

На архитектуре x86 незачем содержать 64-битный тип size_t, т.к. все вопросы размера и позиции блока памяти укладываются в размер регистра общего назначения - в 4 байта. Размер типа size_t на архитектуре x86 равен 32 битам. На архитектуре x64 тип size_t уже будет занимать положенные 8 байт. С мобильными архитектурами все точно так же. Об этом и говорит статус Implementation-definedв стандарте: размер количественной или позиционной характеристики блока памяти определяется деталями целевой архитектуры и всегда достаточно велик чтобы безопасно хранить свое значение.

Ну и еще на счет вот этого.

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

Есть такая штука, как ранкинг целочисленных типов. Ты используешь меньший тип и думаешь что он используется, но на деле будет использоваться тип с большим размером, согласованным с размером регистра общего назначения.
И все бы круто, но эта оптимизация в неумелых руках ведет прямо в Undefined Behavior (искать по словам: "мы забываем о расширении целых типов").
Т.е. ты вполне понимаешь что ты советуешь человеку.