Trivially relocatable
В C++ есть большая группа людей (включая меня), которая любит брать оптимизации из C -- mem* функции возможно являются сильнейшим преимуществом C перед многими другими языками в перформансе. В C++ об этом думали и делали аттрибут std::trivially_copyable, который разрешает копировать как memcpy. Отлично работает на примитивных структурах и в целом C++ такой быстрый в том числе и из-за этого.
Но бывают и более интересные кейсы. Когда вы добавляете элементы в std::vector, рано или поздно вам надо будет реаллоцировать. Вы будете копировать числа/делать std::move объектов из предыдущего вектора. В ситуации с числами можно звать memcpy, они тривиальны, всё отлично. Но на самом деле звать memcpy можно и не только на тривиально копируемые типы, а, например, на unique_ptr, или QString (который с ref count), или vector!
Ведь копирование указателей, чисел вида размера/вместимости при тривиальном std::move ни к чему плохому не приведёт. К сожалению, по стандарту так нельзя. Когда вы начинаете делать mem* функции на типы, у которых примитивный std::move, то стандарт ничего для этого не приготовил и только говорит, что вы обязаны вызвать деструктор, и memcpy не позволяет начать жизнь более сложных объектов.
Поэтому в последние лет 6 идёт борьба за то, чтобы внести понятие тривиально релоцируемых типов -- у которых move оператор и move конструкторы устроены так, что это просто копирование по битам. Если быть точным, нужно ещё, чтобы деструктор не делал странных вещей, например, ничего не делал для пустых векторов, нулевых указателей и тд.
Без этого вставки в середину вектора, удаления из векторов долго не могли использовать memcpy тоже для таких типов. Существует ряд оптимизаций, который открывается из этого. В том числе interop с Rust станет слегка попроще :)
6 лет бились (первые года 4 не сильно, комитету в целом нравилось предложение), и таки уехало в феврале этого года в C++26.
Есть отличный блог из 5 небольших частей почитать о том, как это устроено в Qt.
Сам пропозал
https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2025/p2786r13.html#abstract
В C++ есть большая группа людей (включая меня), которая любит брать оптимизации из C -- mem* функции возможно являются сильнейшим преимуществом C перед многими другими языками в перформансе. В C++ об этом думали и делали аттрибут std::trivially_copyable, который разрешает копировать как memcpy. Отлично работает на примитивных структурах и в целом C++ такой быстрый в том числе и из-за этого.
Но бывают и более интересные кейсы. Когда вы добавляете элементы в std::vector, рано или поздно вам надо будет реаллоцировать. Вы будете копировать числа/делать std::move объектов из предыдущего вектора. В ситуации с числами можно звать memcpy, они тривиальны, всё отлично. Но на самом деле звать memcpy можно и не только на тривиально копируемые типы, а, например, на unique_ptr, или QString (который с ref count), или vector!
Ведь копирование указателей, чисел вида размера/вместимости при тривиальном std::move ни к чему плохому не приведёт. К сожалению, по стандарту так нельзя. Когда вы начинаете делать mem* функции на типы, у которых примитивный std::move, то стандарт ничего для этого не приготовил и только говорит, что вы обязаны вызвать деструктор, и memcpy не позволяет начать жизнь более сложных объектов.
Поэтому в последние лет 6 идёт борьба за то, чтобы внести понятие тривиально релоцируемых типов -- у которых move оператор и move конструкторы устроены так, что это просто копирование по битам. Если быть точным, нужно ещё, чтобы деструктор не делал странных вещей, например, ничего не делал для пустых векторов, нулевых указателей и тд.
Без этого вставки в середину вектора, удаления из векторов долго не могли использовать memcpy тоже для таких типов. Существует ряд оптимизаций, который открывается из этого. В том числе interop с Rust станет слегка попроще :)
6 лет бились (первые года 4 не сильно, комитету в целом нравилось предложение), и таки уехало в феврале этого года в C++26.
Есть отличный блог из 5 небольших частей почитать о том, как это устроено в Qt.
Сам пропозал
https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2025/p2786r13.html#abstract