Существует ли тенденция избегать size_t, если это возможно?

Question

[floppa322]

Всем привет
Существует ли тенденция избегать size_t из-за того, что он является беззнаковым, например, чтобы не попасть на неожиданные signed/unsigned promotion'ы или остатки по модулю 2^N ?

Имея что-то вроде

template<typename T>
inline T static_cast_size_t(size_t value)
{
    #ifdef DEBUG
    if (value > std::numeric_limits<T>::max())
    {
        ASSERT(false);
    }
    return static_cast<T>(value);
    #else
    return static_cast<T>(value);
    #endif
}

// ....
// ....
// ....

// Применять как-то так:
int exampleNum = static_cast_size_t<int/*Или int_fast32, главное, что знаковый*/>(vector.size());
// ...
int numThatCanBeNegative = static_cast_size_t<int/*Или int_fast32, главное, что знаковый*/>(sizeof(U)) - someValue;
// ...

К сожалению, не нашёл guideline'ов ни по поводу size_t, ни int*_t, ни int_fast*

Comments

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

floppa322 ,

тенденция избегать size_t из-за того, что он является беззнаковым, например, чтобы не попасть на неожиданные signed/unsigned promotion'ы или остатки по модулю 2^N ?

Специально выделю в цитату чтобы показать что я это прочитал. Потому что.

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

[floppa322]

Евгений Шатунов, например, чтобы случайно не написать что-то вроде

if ((sizeof(int) - 10) > 100)
    {
        std::cout << "Greater than 100" << "\n";
    }
    else
    {
        std::cout << "Less or equal than 100" << "\n";
    }

Программист, в реальном коде (где -10 и 100 не являлись бы константами) ожидал бы попасть в else блок, а не if
Не просто же так в яндекс код стайле запрещено отнимать от беззнаковых типов, насколько мне известно

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

floppa322, не, программист в реальном коде увидел бы сразу что тут написана дичь :)
Однако, приведенный тобой код с оговорками иногда случается на практике. И от таких ситуаций люди просто предохраняются всего одним сравнением. Это очень просто сделать и такую ситуацию очень легко предотвратить.

Гораздо сложнее обстоят дела с точно такой же проверкой знакового целого. Представь себе что в блоке else ожидается строго неотрицательное значение (sizeof(int) - 10). О проверке на неотрицательность мы ровно так же забыли, как и о проверке переполнения с беззнаковым размером.
И в результате твой же собственный код ровно так же приплыл, просто в другом месте.

И еще интереснее дела обстоят с переполнением знакового - т.е. с UB в коде. Я когда-то уже имел дело с профессиональным кодом профессионального игрового движка, где есть свой STL и в нем все размеры указываются в int. И знаешь что? Там UB изо всех щелей торчит в коде. Тут размер выделили, там умножили, сям прибавили и... ой... UB...
А ведь, на секундочку, переполнение int наступает уже просто тогда, когда ты решаешь выделить битовую матрицу 8192x8192 с ячейкой в 64 бита. Или битовый объем 512*512*512 с ячейкой 32 бита. Там выходит ровно 4ГБит информации. Да, такие размеры иногда бывают нужны. Это всего 536МБ.
А еще с int в качестве размера все время приходится проверять на соответствие диапазону вместо одиночной проверки для беззнакового.

Но и это еще не все. Чтобы увидеть надуманность твоих доводов в комментариях к решению, достаточно просто прочитать документацию. Яб оформил свою речь в ответ если бы обладал достаточным временем. Но времени у меня сейчас нет. Поэтому оставляю этот момент с документацией на тебя. :)

[floppa322]

где есть свой STL

EASTL ?)

Спасибо за развёрнутый ответ
Хз, у меня какая-то фобию unsigned'ов из-за их хитрвых приведений, сначала к singed, потом обратно. Поэтому подумал, что не я 1 такой и что люди пытаюстя по возможности unsigned'ы, и в частности size_t не использовать

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

floppa322, инструмента боится тот, кто не умеет им пользоваться :)
Integral promotion [?] имеет место всегда быть и нередко приводит к UB для знаковых типов.
Советую тебе бороться со страхом через познание.

EASTL ?)

Не, свой, кондовый, самописный с нуля еще в нулевых и нерабочий сегодня более чем на половину.
Дело в том, что среди слабо квалифицированных пользователей C++ бытует мнение что для беззнаковых типов генерируется более тяжелый код с поведением wrap around, в то время как UB - это поведение, которого не может быть. И вот в умах таких людей уже зреет мнение о том, что код работы со знаковыми значительно быстрее.
Но реальности плевать на их фантазии, целочисленная арифметика работает как и должна.

Чисто к слову. Для size_t Integral promotion не выполняется по своему определению.

[floppa322]

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

Чисто к слову. Для size_t Integral promotion не выполняется по своему определению.

Так size_t это же unsigned int просто

Answer 1

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

Если есть риск присванивания знакового значения в беззнаковое, компилятор выдаст WARNING

Гораздо опаснее пихать всюду int, особенно в качестве индексов массивов и размеров. Потому что в какой-то момент кто-то захочет посчитать больше 2^31 штук объектов.

Выдержка из материала по ссылке:

большое количество диагностических сообщений, выдаваемых анализатором Viva64, связанны именно с рекомендацией использования memsize-типов. Использование memsize типов (таких как size_t, ptrdiff_t, INT_PTR) в 64-битных программах, вместо 32-битных типов (int, unsigned) позволяет:

Построить компилятору более простой и, следовательно, более быстрый код, в котором будут отсутствовать лишние преобразования 32-битных и 64-битных данных. Особенно это полезно при работе с адресной арифметикой и индексации массивов.
Избежать ряда ошибок при обработке большого объема входных данных, когда количество обрабатываемых элементов превышает количество UINT_MAX.
Избежать ряда других, более специфичных ошибок.
Сделать код более переносимым между 64-битными Windows и Linux системами, в которых используются различные модели данных. Так, например, в Linux системах для индексации больших массивов можно использовать тип unsigned long, а в Windows нет.

Comments

[floppa322]

Построить компилятору более простой и, следовательно, более быстрый код, в котором будут отсутствовать лишние преобразования 32-битных и 64-битных данных. Особенно это полезно при работе с адресной арифметикой и индексации массивов.
Избежать ряда ошибок при обработке большого объема входных данных, когда количество обрабатываемых элементов превышает количество UINT_MAX.
Избежать ряда других, более специфичных ошибок.
Сделать код более переносимым между 64-битными Windows и Linux системами, в которых используются различные модели данных. Так, например, в Linux системах для индексации больших массивов можно использовать тип unsigned long, а в Windows нет.

Тогда лучше использовать знаковый int_fast32 нет опасных promotion'ов и в 64 битных системах работать быстро будет

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

floppa322, разработчики стандарта языка не такие уж и глупцы, раз обвешали всю стандартную библиотеку этим size_t.

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

[floppa322]

floppa322, разработчики стандарта языка не такие уж и глупцы, раз обвешали всю стандартную библиотеку этим size_t.

Предполагаю, что это просто легаси. Ну и в любом случае, методы контейнеров вроде size(), должны возвращать такой тип, чтобы, например, на 64 битной системе можно было в вектор положить больше, чем int_64, то есть unsigned long. Но в реальности то в контенерах почти никогда столько элементов не лежит, а в свою очередь беззнаковые типы несут некоторую боль
И size_t (cppreference.com)

std::size_t can store the maximum size of a theoretically possible object of any type (including array). A type whose size cannot be represented by std::size_t is ill-formed (since C++14) On many platforms (an exception is systems with segmented addressing) std::size_t can safely store the value of any non-member pointer, in which case it is synonymous with std::uintptr_t.

std::size_t is commonly used for array indexing and loop counting. Programs that use other types, such as unsigned int, for array indexing may fail on, e.g. 64-bit systems when the index exceeds UINT_MAX or if it relies on 32-bit modular arithmetic.

И int_fast*
(stdint.h)

/* Signed.  */
typedef signed char		int_fast8_t;
#if __WORDSIZE == 64
typedef long int		int_fast16_t;
typedef long int		int_fast32_t;
typedef long int		int_fast64_t;
#else
typedef int			int_fast16_t;
typedef int			int_fast32_t;
__extension__
typedef long long int		int_fast64_t;
#endif

Зависят от разрядности системы (64/32). Но при этом знаковый int_fast* устраняет проблемы signed/unsigned promotion'ов, в отличие от беззнакового size_t

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

Наоборот же беззнаковые (size_t) в знаковые

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

floppa322, так вы все равно предлагаете прикрывать дыру газеткой, причем опасным способом. Вот родился у вас массив в 4 млрд элементов, в int его размер не уместился. В дебаге вы упадете, а в релизе у вас полезет UB, причем с возможной порчей данных, которую юзер не заметит и сохранит. Так что если уж вы нашли фатальную проблему (которую сами себе создали), нужно падать безусловно, а не только в дебажных сборках.

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

[floppa322]

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

floppa322, так вы все равно предлагаете прикрывать дыру газеткой, причем опасным способом. Вот родился у вас массив в 4 млрд элементов, в int его размер не уместился. В дебаге вы упадете, а в релизе у вас полезет UB, причем с возможной порчей данных, которую юзер не заметит и сохранит. Так что если уж вы нашли фатальную проблему (которую сами себе создали), нужно падать безусловно, а не только в дебажных сборках.

Здесь компромисс нужен, ведь можно точно так же упасть из-за тех же неучтённых приведений знаковых/беззнаковых типов

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

Ну, поскольку, гайдлайнов я не нашёл по тому же int_fast*, могу предположить, что в 99% случаях нужно использовать int_fast32 вместо int'а (из-за скорости) или беззнакового size_t (из-за приведения знаковых/беззнаковых типов), за исключением массивов, потому что скорее всего массив int будет работать быстрее массива int_fast32 из-за того, что будет вдвое меньше памяти занимать, а следовательно будет в 2 раза меньше кэш промахов. Ну и в объектах, из которых могут быть составлены большие массивы, тоже, наверное, следует использовать int вместо int_fast32 по тем же причинам. В общем скорее всего int_fast32 лучше использовать как локальные переменные, либо в объектах, но с осторожностью, когда не предполагается больших массивов из таких объектов

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

floppa322, это называется "преждевременная оптимизация". Ваш прогноз умозрителен и требует проверки на реальных алгоритмах и реальных данных.

В частности, используя индексы в интах, вы ограничиваете работоспособность вашей программы - она сможет индексировать только массивы длиной 2^31 элементов.

Что касается (якобы) отсутствия гайдлайнов - я не зря сослался на материал (автор которого - разработчик статического анализатора кода на C++), в нем есть ссылки на другие статьи автора по темею

[floppa322]

Армянское Радио, ну ок, поищу там, может быть что-нибудь найду