std::launder: зачем и когда нужен

Привет, Хабр!

Сегодня разберём мутный, но крайне важный инструмент — std::launder. Мы поглядим, зачем его протащили в C++17 и что компилятор делает, когда видит launder.

Немного истории

До C++03 стандарт утешал нас иллюзией: если вы вызвали placement new поверх старого объекта того же типа, старый указатель волшебно начинает указывать на новый объект. В 2004-м в стандарт вкрался пункт, запрещающий такое перерождение, если тип имел const‑поля или был сабобъектом внутри другого типа. Но по факту около 40% placement‑конструкций в их кодовой базе игнорировали это правило и формально были Undefined Behavior.

Пришлось срочно латать дыру, не переписывая пол‑интернета. Так появился std::launder — стационар в психбольнице для указателя: заходит грязным, выходит чистым и с новой историей.

Кейс: переконструкция объекта in-place

Без launder — классическое UB

struct Widget {     const int id;     std::string name; };  alignas(Widget) std::byte buf[sizeof(Widget)]; auto *p = new (buf) Widget{1, "old"}; p->~Widget(); new (buf) Widget{2, "new"};  std::cout << p->id << '\n';   // UB: p указывает на покойника

Старый p помнит старый объект. Компилятор вправе закэшировать id == 1 навсегда.

С launder все адекватней

auto *q = std::launder(reinterpret_cast<Widget*>(buf)); std::cout << q->id << '\n';   // 2, жизнь удалась

std::launder формально не создаёт объект, а дает доступ к уже живущему объекту; его lifetime должен быть начат до стирки, это важно.

Что делает компилятор

Alias-barrier: что именно «забывается»

Value Range — константные значения const‑полей, которые могли быть закэшированы в VRP/GVN.

Type‑based AA — привязка «lvalue — объект» разрывается; все последующие загрузки обязаны идти в память.

Devirtualization — если вы placement new‑ом заменили объект с виртуальными методами, старый vptr больше не легитимен; launder принудительно откатывает результаты Devirt‑pass.

Capture Tracking — LLVM‑intrinsic помечен HasUnknownCapture, поэтому -flto не вырезает его даже при межмодульном анализе.

Поведение в constexpr-контексте

Почти все фронтенды компилируются так:

constexpr int f() {     alignas(int) std::byte buf[sizeof(int)];     // new не вызвали → lifetime не начат     return *std::launder(reinterpret_cast<int*>(buf)); // hard error }

__builtin_launder в Clang ≥ 17 и GCC > 13 помечен как Immediate Invocation, т. е. проверяется ещё до константного фолдинга: если объекта нет — diagnostic на этапе semantic analysis. А если lifetime уже начат (например, через new или std::start_lifetime_as), код спокойно вычисляется в constexpr.

launder ≠ std::start_lifetime_as

Т.е порядок действий классический:

1. start_lifetime_as<T> → загрузили снапшот/выделили арену.

2. …манипулируем байтами…

3. std::launder → обращаемся к объекту и гарантируем, что оптимизатор не смотрит в прошлое.

Как проверить, что барьер действительно работает

• Godbolt: сравните -O3 дампы с и без launder — пропадёт ли константное mov $1, %eax при обращении к const‑полю.

• LLVM opt‐pipeline: после -passes=devirt,gvn вызов intrinsic, всё ещё на месте → значит, alias‑fence отработал.

• GCC: запустите -fdump-tree-optimized — увидите, что __builtin_launder остаётся вплоть до RTL, а затем исчезает.

Практика

Итак, посмотрим, где можно юзать все это дело.

TinyOptional 2.0: с поддержкой перемещений и constexpr

template<class T> class TinyOptional {     static constexpr std::size_t N = sizeof(T);     alignas(T) std::byte storage[N];     bool engaged = false;      T* ptr() noexcept {         return std::launder(reinterpret_cast<T*>(storage));     }  public:     constexpr TinyOptional() noexcept = default;      constexpr TinyOptional(const TinyOptional& rhs)         requires std::is_copy_constructible_v<T>     {         if (rhs.engaged) emplace(*rhs.ptr());     }      constexpr TinyOptional(TinyOptional&& rhs) noexcept         requires std::is_move_constructible_v<T>     {         if (rhs.engaged) emplace(std::move(*rhs.ptr()));     }      template<class... Args>     constexpr T& emplace(Args&&... args) {         reset();         ::new (storage) T(std::forward<Args>(args)...);         engaged = true;         return *ptr();     }      constexpr void reset() noexcept {         if (engaged) {             std::destroy_at(ptr());           // C++20 helper             engaged = false;         }     }      constexpr explicit operator bool() const noexcept { return engaged; }      constexpr T& value() & {         if (!engaged) throw std::bad_optional_access{};         return *ptr();                        // UB-safe: launder внутри     }      constexpr ~TinyOptional() { reset(); } };

Без стирки value() нарушает [basic.life]: если у T есть const‑поля или он ― сабобъект, оптимизатор вправе считать, что указатель до переконструкции и после — тот же объект.

Почему не std::optional? Иногда нужен trivial класс, который укладывается в std::atomic<TinyOptional<T>> или живёт в шёрстке ядра драйвера, где нельзя тащить тяжёлый <optional>.

Арена «all-in-one и ни шагу назад»

class LinearArena {     static constexpr std::size_t CAP = 4'096;     alignas(std::max_align_t) std::byte mem[CAP];     std::size_t head = 0;  public:     template<class T, class... Args>     requires (std::alignof_v(T) <= alignof(std::max_align_t))     T* make(Args&&... args) {         if (head + sizeof(T) > CAP) throw std::bad_alloc{};         void* here = mem + head;         head += sizeof(T);         return ::new (here) T(std::forward<Args>(args)...);     }      template<class T>     void destroy(T* obj) noexcept {         // «Стирка» рвёт alias-связи, чтобы оптимизатор не выкидывал dtor         std::destroy_at(std::launder(obj));         // head не откатываем: арена линейная, можно сбросить целиком     }      void reset() noexcept { head = 0; }       // mass-free };

Почему нужен launder в destroy? Если клиент сохранил старый указатель и потом плэйс­мен­т‑конструировал новый объект тем же типом поверх него, у компилятора возникнет соблазн оптимизировать повторный деструктор как dead store.

Фриз-снапшот / «холодная» десериализация

struct Header { std::uint32_t magic; std::uint32_t size; }; struct Payload { std::array<char, 64> data; };  auto blob = read_file("snapshot.bin");        // raw bytes auto* raw = blob.data();  const Header* h = std::launder(reinterpret_cast<Header*>(raw)); if (h->magic != 0xDEADBEEF) throw BadFormat{};  const Payload* body = std::launder(         reinterpret_cast<Payload*>(raw + sizeof(Header)));  process_payload(*body);

Почему не std::bit_cast? Мы не просто копируем биты: нам нужен живой объект со всеми конструкторскими инвариантами.

А что с alignment? Формат задаёт alignas(Header) и alignas(Payload); если файл записан на другой платформе — проверяем.

C++23-версия. Более формально корректно:

auto* h = std::start_lifetime_as<Header>(raw); auto* body = std::start_lifetime_as<Payload>(raw + sizeof(Header));

а launder уже не нужен: lifetime начат правильным инструментом.

Variant-light

enum class StateTag { Idle, Busy };  struct Idle  { /* … */ }; struct Busy  { int job_id; /* … */ };  struct FSM {     StateTag tag = StateTag::Idle;     alignas(Busy) std::byte buf[sizeof(Busy)];      Idle*  idle()  { return std::launder(reinterpret_cast<Idle*>(buf)); }     Busy*  busy()  { return std::launder(reinterpret_cast<Busy*>(buf)); }      void enter_idle() {         if (tag == StateTag::Busy) std::destroy_at(busy());         ::new (buf) Idle{};         tag = StateTag::Idle;     }     void enter_busy(int id) {         if (tag == StateTag::Busy) std::destroy_at(busy());         ::new (buf) Busy{id};         tag = StateTag::Busy;     } };

std::variant здесь бы дал лишние 16 Б на тег + vtable‑подобную надбавку, а нам нужна компактность. При многократном переходе Busy ту Busyоптимизатор не кэширует старое job_id.

Когда точно ставить launder

Стоит ли юзать launder в продакшене?

Коротко: почти никогда.

Если вы не пишете свой optional/variant/контейнер — забудьте. В обычном бизнес‑коде хватает RAII + смарт‑указателей. Ошибиться с launder легко: он не вызывает конструктор, не проверяет выравнивание, не начинает lifetime.

Но знать о нём нужно, чтобы:

1. Читать чужой low‑level код и не пугаться UB.

2. Уметь объяснить зачем комьюнити протащило такую деталь сборки.

3. В редких высокопроизводительных подсистемах (арены, ECS‑движки, custome allocators) выбрать правильный инструмент: start_lifetime_as, bit_cast, launder или plain placement new.

---

Итоги

std::launder — маленькая функция, закрывающая огромную дыру между моделью памяти стандарта и агрессивным оптимизатором. Она:

• Инвалидирует прежние предположения компилятора о содержимом адреса.

• Гарантирует корректный доступ к объекту, чья жизнь была начата «в обход» предыдущего указателя.

• Не создаёт объект и не решает все проблемы lifetime; в 2023+ за это отвечает std::start_lifetime_as.

Делитесь своим опытом в комментариях.

---

Если вы когда-либо писали на C++, вы знаете: ошибка, пропущенная на этапе разработки, может аукнуться где угодно — от багрепорта в проде до ночного алерта. Особенно если код собирали в спешке, без времени на рефакторинг или валидацию.

Чтобы таких ситуаций было меньше — и багов, и бессмысленного дебага — загляните на открытые уроки, на которых будут разборы практик и приёмов, которые реально работают в боевом C++-коде:

• 9 июня в 20:00
  Отлаживаем C++: от printf до asan и зеленых тестов
  Разберёмся, как системно находить баги, где помогает core dump, когда стоит подключать valgrind и почему assert не устарел.

• 19 июня в 20:00
  Разделяй и абстрагируй: как создавать понятный C++ код
  Пошаговый рефакторинг: меньше сломанных абстракций, больше читаемого кода и никаких компромиссов с производительностью.