Чисто к слову. Для size_t Integral promotion не выполняется по своему определению.
if ((sizeof(int) - 10) > 100)
{
std::cout << "Greater than 100" << "\n";
}
else
{
std::cout << "Less or equal than 100" << "\n";
}floppa322, так вы все равно предлагаете прикрывать дыру газеткой, причем опасным способом. Вот родился у вас массив в 4 млрд элементов, в int его размер не уместился. В дебаге вы упадете, а в релизе у вас полезет UB, причем с возможной порчей данных, которую юзер не заметит и сохранит. Так что если уж вы нашли фатальную проблему (которую сами себе создали), нужно падать безусловно, а не только в дебажных сборках.
Проблема должна решаться для каждого кода индивидуально, а не глобальной заменой всех переменных в программе на int_fast* с сомнительной конвертацией.
floppa322, разработчики стандарта языка не такие уж и глупцы, раз обвешали всю стандартную библиотеку этим size_t.
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.
/* 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
А если у вас где-то в коде случается перекидываение знаковых данные в беззнаковые, в этом месте нужно делать проверку корректности, а не прикрывать дыру газеткой.
Построить компилятору более простой и, следовательно, более быстрый код, в котором будут отсутствовать лишние преобразования 32-битных и 64-битных данных. Особенно это полезно при работе с адресной арифметикой и индексации массивов.
Избежать ряда ошибок при обработке большого объема входных данных, когда количество обрабатываемых элементов превышает количество UINT_MAX.
Избежать ряда других, более специфичных ошибок.
Сделать код более переносимым между 64-битными Windows и Linux системами, в которых используются различные модели данных. Так, например, в Linux системах для индексации больших массивов можно использовать тип unsigned long, а в Windows нет.
Только тебе снова придется справляться с проблемой отсутствия поля в твоем классе и я бы хотел сперва узнать, как ты планируешь это обходить.
И часто забываемый, но крайне важный пункт про проектирование. Здесь нарушен Single responsibility принцип, что возможно и породило этот вопрос. Т.е. у Вас метод по добавлению элемента может удалять/заменять элементы, что должно вызвать вопросы. Более того, вы решили за клиента вашего API (даже если это и Вы сами) как нужно обрабатывать исключительную ситуацию по переполнению. Потом например вы решите, что в одном месте стоит сложить старые элементы в отдельную очередь в другом залогировать или удалять не по одному, а сразу половину буффера. Все это потребует переписывания метода add, а зачем и почему? Попробуйте убрать эту часть кода заменив на выбрасывание исключения или вариант с возвращением успешности операции (менее грамотное решение, но это уже из области субъективной оценки) и посмотреть как увеличится прозрачность и простота написания клиентского кода для этого метода. Еще стоит посмотреть на сходное проектное решение в std::vector и его методе pop_back. Подумайте почему он не возвращает удаленный элемент?
https://www.youtube.com/channel/UCGlYKd-FR4g0Tp4wF...