(Естественно, принимается что вопрос alignment Foo и Bar решён (или они оба packed)).
Однако я не нашёл в стандарте C++20 упоминания, что reinterpret_cast может начать lifetime объекта. Хотя malloc и memcpy теперь легальны с этой точки зрения, т.е. этот пропозал был включён в стандарт, но обошли reinterpret_cast.
Здравствуйте, Ip Man, Вы писали:
IM>Однако я не нашёл в стандарте C++20 упоминания, что reinterpret_cast может начать lifetime объекта. Хотя malloc и memcpy теперь легальны с этой точки зрения, т.е. этот пропозал был включён в стандарт, но обошли reinterpret_cast.
Вроде для этого предложили новую функцию std::start_lifetime_as ,
но не знаю принята она в стандарт или нет.
Здравствуйте, Zhendos, Вы писали:
IM>>Однако я не нашёл в стандарте C++20 упоминания, что reinterpret_cast может начать lifetime объекта. Хотя malloc и memcpy теперь легальны с этой точки зрения, т.е. этот пропозал был включён в стандарт, но обошли reinterpret_cast.
Z>Вроде для этого предложили новую функцию std::start_lifetime_as ,
Надо больше обрядов. Что это за религия если мало странных обрядов
Здравствуйте, reversecode, Вы писали:
R>это бред R>у гугла до черта кода которые делаю такие касты R>их uint8_t* в какой то объект(структуру)
R>и если это УБ R>то прощай весь софт, так же ?
Здравствуйте, Ip Man, Вы писали:
IM>Все так делают. Но формально это UB.
В тему приглашается 45й который на скиле по хардкору пояснит что нет никаких проблем писать код, не содержащий уб, и что его достало нытьё неосиляторов и что нет ничего сложного пофиксить старый проект и пересобрать более новым компилятором.
Здравствуйте, T4r4sB, Вы писали:
IM>>Все так делают. Но формально это UB. TB>В тему приглашается 45й который на скиле по хардкору пояснит что нет никаких проблем писать код, не содержащий уб, и что его достало нытьё неосиляторов и что нет ничего сложного пофиксить старый проект и пересобрать более новым компилятором.
code review обычно не пройдёт: big-endian/little-endian, проверка размера прочитанных данных, проверка диапазонов значений — где всё это? А без таких проверок reinterpret_cast смысла не имеет.
Modifying a const object through a non-const access path and referring to a volatile object through a non-volatile glvalue results in undefined behavior.
То есть этот код содержит УБ?
int g=0;
int bar() {
++g;
return g;
}
int foo(const int& a) {
return a + bar() + a;
}
int main() {
printf("%i\n", foo(g));
}
Modifying a const object through a non-const access path and referring to a volatile object through a non-volatile glvalue results in undefined behavior
Здравствуйте, Ip Man, Вы писали:
IM>(Естественно, принимается что вопрос alignment Foo и Bar решён (или они оба packed)).
А почему placement new тут не используется с параметром выравнивания?
Здравствуйте, σ, Вы писали:
σ>А где в нём происходи что-нибудь из цитируемого?
Модификация константного объекта через неконстантный доступ.
Или "константный объект" это только то, что изначально объявлено с модификатором const, а не результат разыменования const&?
Здравствуйте, T4r4sB, Вы писали:
TB>Или "константный объект" это только то, что изначально объявлено с модификатором const, а не результат разыменования const&?
Только объект, что изнчально был const.
На одной пратформе компилятор может расположить его в обычной оперативной памяти, на другой — помеместить в области памяти с защитой от записи, на третьей — вообще оставить в ROM. Универсального ответа что произойдёт при попытке изменить такой объект нет — поэтому декларируется неопределённое поведение.
Здравствуйте, Ip Man, Вы писали:
IM>Здравствуйте, Kernan, Вы писали:
K>>А почему placement new тут не используется с параметром выравнивания?
IM>Стандарт не гарантирует. Объект-то будет создан и даже default initialized, но нигде не сказано, что там останутся те же байты.
Погоди. Это как? placement new же не меняет память, а работает поверх того что есть. Кроме того, вроде с POD точно должно быть нормально. Разве нет?
IM>>Стандарт не гарантирует. Объект-то будет создан и даже default initialized, но нигде не сказано, что там останутся те же байты. K>Погоди. Это как? placement new же не меняет память, а работает поверх того что есть. https://timsong-cpp.github.io/cppwp/n4868/basic.indet#1
TB>Modifying a const object through a non-const access path and referring to a volatile object through a non-volatile glvalue results in undefined behavior.
