Да, есть такое дело. Но ведь в C++23 завозят std::start_lifetime_as и, поскольку в статье речь идет о C++26, может быть std::start_lifetime_as уместнее, чем std::launder?
PS. На самом деле я сам не знаю, что правильно. До C++23 вроде как std::launder необходим хотя бы для очистки совести. На вот начиная с C++23...
А точно ли здесь нужно использование std::launder? Вроде бы объект типа T инстанциируется корректно, затем его тип не меняется, а кастинг из std::byte* в T* полностью легален.
Во-первых, сложно и геморройно. Охота за утечками памяти в начале-середине 1990-х годов была одним из основных занятий при разработке на C++.
Во-вторых, умные указатели появились отнюдь не вместе с C++11. Я сам их начал использовать на повседневной основе во второй половине 1990-х (при этом не был пионером, а подсмотрел в чужих разработках, так что умные указатели в мире C++ уже лет тридцать как, если не больше). Ну а самый простой из них под видом std::auto_ptr был прямо в С++98.
ИМХО, этот момент имеет смысл отразить в статье. Потому что выравнивание -- это штука, про которые не все помнят, а кто-то и не знает. Скопируют ваш подход и наступят на грабли где-нибудь.
Могу ли я предположить, что игровой движок -- это небольшая часть конкретного игрового проекта и тот прессинг багов и нереализованных хотелок, про который упоминает автор статьи, относится не к игровому движку?
https://en.cppreference.com/w/cpp/links/libs -- этот список никакой не "официальный" Не знаю как сейчас, а несколько лет назад на cppreference можно было зарегистрироваться и внести изменения в wiki-страничку со списком библиотек. Так что там список того, что успели и не поленились добавить на эту wiki-страничку. Попасть в список awesome-cpp чуть сложнее, там (емнип) PR отправлялся и этот PR ждал пока его примут.
Потому что ее нет, вот и кажется, что это манна небесная. А как появится, как распробуем, так и начнем мечтать еще о чем-то недоступном в ожидании чуда :)
Я хочу сказать, что в интернете уже столько развенчаний мифов о UB с наглядными примерами того, как UB стреляет по ногам, что нужно быть очень высокого мнения о себе чтобы пускаться в рассуждения о детерминизме компилятора.
Названия в CAPS_LOCK-е принято давать в C-шных макросах. Поэтому если вы у себя в проекте подключаете заголовок из чисто-сишной либы, то к вам могут прилететь макросы, о которых вы даже не подозреваете. И ваш код начнет вести себя непредсказуемо (хорошо хоть, что в основном во время компиляции).
Я так когда-то наступил на грабли с названием LOG_ERR (или чем-то подобным).
Названия перечислений и константные значения, на сколько я помню, принято указывать заглавными буквами.
Семантика слова reset подразумевает установку первоначального значения.
Как бы reset означает сброс того, что было установлено раньше. Будет ли результат reset-а начальным значением или нет -- это уже от предметной области зависит.
Да, есть такое дело.
Но ведь в C++23 завозят
std::start_lifetime_asи, поскольку в статье речь идет о C++26, может бытьstd::start_lifetime_asуместнее, чемstd::launder?PS. На самом деле я сам не знаю, что правильно. До C++23 вроде как
std::launderнеобходим хотя бы для очистки совести. На вот начиная с C++23...А точно ли здесь нужно использование
std::launder?Вроде бы объект типа T инстанциируется корректно, затем его тип не меняется, а кастинг из
std::byte*вT*полностью легален.Мой ответ вам -- это был сарказм на 146%. И речь шла про то, что в программировании еще никому не удавалось не совершать ошибок.
Неужели и вы про это?
Вы сейчас серьезно?
Так очевидно же, что писать на C++ без утечек памяти, use after free и double free просто: достаточно не совершать ошибок. Делов-то.
Во-первых, сложно и геморройно. Охота за утечками памяти в начале-середине 1990-х годов была одним из основных занятий при разработке на C++.
Во-вторых, умные указатели появились отнюдь не вместе с C++11. Я сам их начал использовать на повседневной основе во второй половине 1990-х (при этом не был пионером, а подсмотрел в чужих разработках, так что умные указатели в мире C++ уже лет тридцать как, если не больше). Ну а самый простой из них под видом std::auto_ptr был прямо в С++98.
ИМХО, этот момент имеет смысл отразить в статье. Потому что выравнивание -- это штука, про которые не все помнят, а кто-то и не знает. Скопируют ваш подход и наступят на грабли где-нибудь.
Ясно-понятно, вопросов больше не имею.
Кем и как этот размер подбирается?
Это утверждение относится к игровым движкам или к программированию на C++ вообще?
Нет ли здесь:
проблем с выравниванием для типа
_type?Скажем, sizeof(counterSize) у вас 4, а выравнивание для
_type-- 8.Звучит так, что "долгоживущий код" -- это редкость.
А зачем их брать? Или вы их тоже ревьювите?
Могу ли я предположить, что игровой движок -- это небольшая часть конкретного игрового проекта и тот прессинг багов и нереализованных хотелок, про который упоминает автор статьи, относится не к игровому движку?
https://en.cppreference.com/w/cpp/links/libs -- этот список никакой не "официальный"
Не знаю как сейчас, а несколько лет назад на cppreference можно было зарегистрироваться и внести изменения в wiki-страничку со списком библиотек. Так что там список того, что успели и не поленились добавить на эту wiki-страничку. Попасть в список awesome-cpp чуть сложнее, там (емнип) PR отправлялся и этот PR ждал пока его примут.
А насколько в игрострое распространены случаи, когда однажды написанная кодовая база затем эксплуатируется и развивается на протяжении 10 и более лет?
Стандарт с C++20, но там есть свои особенности.
Потому что ее нет, вот и кажется, что это манна небесная. А как появится, как распробуем, так и начнем мечтать еще о чем-то недоступном в ожидании чуда :)
Я хочу сказать, что в интернете уже столько развенчаний мифов о UB с наглядными примерами того, как UB стреляет по ногам, что нужно быть очень высокого мнения о себе чтобы пускаться в рассуждения о детерминизме компилятора.
Похоже, вы сейчас пытаетесь мне объяснить, что UB в C++ном коде -- это нормально? Ну ну, ну ну.
Если бы.
Названия в CAPS_LOCK-е принято давать в C-шных макросах.
Поэтому если вы у себя в проекте подключаете заголовок из чисто-сишной либы, то к вам могут прилететь макросы, о которых вы даже не подозреваете. И ваш код начнет вести себя непредсказуемо (хорошо хоть, что в основном во время компиляции).
Я так когда-то наступил на грабли с названием LOG_ERR (или чем-то подобным).
В Java :)
Что-то мне подсказывает, что вы еще очень молоды.
Как бы reset означает сброс того, что было установлено раньше. Будет ли результат reset-а начальным значением или нет -- это уже от предметной области зависит.