Объединение параметров шаблона с переменным числом вариантов

Спасибо, что поделились своим наблюдением. Какой у Вас вопрос?

Если каждый экземпляр всегда относится к определенному типу и вы всегда знаете, какой это тип, то зачем вообще использовать объединение? Какую реальную проблему, по вашему мнению, решит такой союз? Это звучит как возможная Проблема XY.

Если вы знаете свои типы, вам не нужен вариант.

Что-то в этом роде , возможно.

@RemyLebeau извиняюсь - вариант использования немного прояснен.

@IgorTandetnik с таким примером, как мы могли бы эффективно извлекать элементы (за O (1))

@ Thornsider3 ваш вариант использования не ясен. Можете ли вы предоставить реальный код, с которым у вас возникли проблемы?

С -O2 вызов get полностью оптимизирован

@RemyLebeau: по крайней мере, как я это читал, контейнер с вещами. В любой момент времени все вещи в контейнере будут одного типа, поэтому нет необходимости хранить тип отдельно для каждого.

@JerryCoffin до сих пор не ясно, почему это должен быть контейнер союзов.

@RemyLebeau: Не уверен, что это действительно так. В этом отношении я не уверен, что моя догадка верна. Я как бы надеялся, что ОП подтвердит или опровергнет это...

@JerryCoffin Представлен фрагмент того, что я пытаюсь сделать (с некоторыми раздражающими деталями TMP, исключенными для удобства чтения), чтобы это было более понятно. Спасибо за ответ.

Спасибо за ваш ответ. Я хочу узнать больше о том, почему работает второе решение. Когда мы приводим buffer к U*, расположение результирующего указателя, безусловно, зависит от U*, так как же C++ узнает, что нужно «привести» его в правильное место? Я также видел, как возникла структура с множественным наследованием, указатель this которой может быть статически приведен к любому из ее родительских типов, и я хотел знать, как это возможно.

@ Thornsider3 static_cast, используемый для приведения указателей в иерархии наследования, и reinterpret_cast совершенно разные. Они не являются взаимозаменяемыми, и в большинстве ситуаций только один из них является правильным и не будет иметь неопределенного поведения. reinterpret_cast из указателя (в данном случае после распада массива на указатель &buffer[0] с типом std::byte*) на любой тип указателя U*, соответствующий типу U, гарантированный здесь с помощью alignas(Ts...), создает другой указатель с тем же значением указателя, но типа U*.

@Thornsider3 Это означает, что reinterpret_cast<U*>(buffer) является выражением типа U* с точно таким же значением, что и &buffer[0], т. е. оно указывает на первый элемент массива. В частности, адрес как часть значения указателя также не изменяется. Поскольку существует несоответствие между типом указателя и типом объекта, на который фактически указывает указатель, прямое использование результата почти всегда является неопределенным поведением.

@Thornsider3 Однако, если вы ранее создали объект U в &buffer[0], который затем вложен в буфер, и этот объект U все еще находится в своем жизненном состоянии, то вы можете использовать std::launder, чтобы изменить значение указателя с указателя на начало буфера. массив в указатель, указывающий на объект U, расположенный по тому же адресу.

@Thornsider3 Если вы не создали объект U, например. new(static_cast<void*>(buffer)) U; внутри буфера или если вы впоследствии создали в нем еще один объект другого типа, то вызов std::launder будет иметь неопределенное поведение. Также обратите внимание, что буфер, очевидно, должен иметь достаточный размер в дополнение к выравниванию, иначе новое размещение будет иметь неопределенное поведение. Кроме того, буфер должен иметь тип std::byte или unsigned char, поскольку это единственные типы, которые указаны для обеспечения хранения для других объектов.

@Thornsider3 static_cast между типами указателей делает что-то совершенно другое и, в отличие от reinterpret_cast, может изменять адрес значения указателя, например. при приведении типа производного класса к типу базового класса, который смещается в хранилище производного класса.

@Thornsider3 «Когда мы приводим буфер к U*, расположение результирующего указателя определенно зависит от U*»: Нет, поскольку вам нужно было бы заранее разместить объект U точно в &buffer[0], невозможно, чтобы потребовалось смещение адреса. и reinterpret_cast никогда не будет добавлять или вычитать какое-либо смещение адреса. Любое другое использование этой конструкции, например. размещение объекта производного класса и последующая попытка получить указатель на базовый класс из buffer вместо этого будет иметь, как и в случае union, неопределенное поведение.

Итак, если я правильно понимаю, *std::launder(reinterpret_cast<U*>(buffer)) работает только в том случае, если U является нашим первым типом, и если мы хотим получить доступ к третьему типу, о существовании которого мы знаем и который, как мы знаем, содержит V, нам понадобится *std::launder(reinterpret_cast<V*>(&buffer[2]))?

@ Thornsider3 Нет, совсем нет. Ваша функция get будет выглядеть просто как template<typename U> U& get() { return *std::launder(reinterpret_cast<U*>(buffer)); }, а ваша функция emplace — как template<typename U, typename... Args> void emplace(Args&&... args) { ::new(static_cast<void*>(buffer)) U(std::forward<Args>(args)...); } или проще template<typename U, typename... Args> void emplace(Args&&... args) { std::construct_at(reinterpret_cast<U*>(buffer), std::forward<Args>(args)...); }

@Thornsider3 Любой из возможных типов в Ts... будет расположен по начальному адресу массива, точно так же, как любой из типов Ts... в случае объединения будет расположен по начальному адресу объединения. Массив как объект сам по себе не важен. Он используется только для хранения, чтобы в объекте tagless_variant было достаточно места для хранения любого из типов Ts..., которые ему могут понадобиться для хранения.