Struct foo_int{ unique_ptr<byte> _buf; int& _int;

foo_int(unique_ptr<byte>&& b) : _buf(move(b), _int(*lounder(reinterpret_cast<int*>) _buf.get())
{}

operator int&() {return _int;}
}

Нормально или уб?

byte в int?

Я ему lounder сказал, все прочее ок

launder может? А есть гарантии, что объект создан?

UB

На сколько я понял lounder, он как раз предназначен для того, чтобы сказать что объект есть. А иначе бы просто каста хватало.

увы, вы не поняли launder

std::launder тесно связан с таким явлением, как transparent replacement: http://eel.is/c++draft/basic#life-8

Если это std::byte и std::launder(), а также есть хотя бы массив этих байтов подходящей для int длины и выравнивания, то нормально с C++20.

а что делать со strict aliasing?

А (нарушения) его там нет: я просто исхожу из предположения, опять же, что под unique_ptr на самом деле массив байтов, а не один байт.

как можно проинициализировать инт, не осуществив доступ к памяти байтов через выражение типа инт?

Так мы осуществляем, просто создание alignas(int) std::byte[sizeof(int)] создает (ретроактивно) и сам int, к которому мы получаем доступ через прачечную (без нее было бы нельзя). Edit: Сам инициализированный int нам же тут не нужен - мы ссылку на него инициализируем же. Т.е. indeterminate-value не вычисляется, если речь об этом.

Там же int& _int

так для инициализации ссылки все равно valid object нужен, которого нет

А почему нет, если массив байтов есть? Я на это положение ссылаюсь, его должно быть достаточно.

массив байтов это не массив интов или вы трактуете этот пункт так, что int создастся неявно в таком массиве?

Разумеется, это же одна из "фундаментальных магий" этих типов в современном языке) Edit: Это работает только в отношении implicit-lifetime-type, разумеется, но int к ним относится.

я нахожу это толкование расширительным, поэтому иду смотреть на документ, из которого этот параграф пришел

Спасибо, добрый человек. А то я совсем загрустил перед перспективой реаллокптор на брутальных сях выписывать.

Несколько удивлен, честно говоря: я предполагал, что эта информация уже давно довольно известна здесь. Если не ошибаюсь, с Вами же не раз уже обсуждали эту тему в т.ч. полагаясь на это положение...

Ок. Я тудой референс-враппер вставлю вместо ссылки. Он, вообще то, реально там - чтобы мув не терять.

Ну замечание про [] выше было уместное: под это unique_ptr специализирован отдельно, чтобы корректно сочетать new/delete.

И надо ещё выравнивание соблюсти

то, что неявное создание объектов работает и под таким углом, для меня скорее новость

какие у вас планы на ссылку, которую возвращает operator int&?

Что, в свою очередь, уже новость для меня =)

возможно, я это забыл когда я думам про неявное создание объектов сейчас, ничего кроме примера с malloc на ум не приходило хотя https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2020/p0593r6.html#type-punning я перечитывал не раз

Но по Вашей ссылке /// new (buffer) std::byte[sizeof(buffer)]; /// То есть создание !массива! Массив в плюсах это вообще отдельная магия не поддающаяся разумению.

Уточните, что именно не поддается разумению в массивах.