Пишем свой вариантный тип

[Kelbon]

std::int16_t curT;
std::array<char, FindMaxSize<0, PTypes...>()> data;

тип индекса можно выбирать в зависимости от числа типов. И байты нужно поместить по правильному алигменту, alignas(alignof(T)) char data[std::max({sizeof(Types)...})];

[KirillVelichk0]

спасибо, что-то не подумал об этом. Сейчас поправлю

[segment]

Можете показать реальное применение этому? Не наброс, для меня остается загадкой любовь к метапрограммированию, я помню как-то закапывался в boost/std и реализовывал свои контейнеры, оно конечно увлекает, но по итогу на простом Си (в embedded) оно реализовалось в более поддерживаемом варианте. Как всё это отлаживать, тестировать и документировать?

[KirillVelichk0]

Секунду. Комментарий поправил

[Kelbon]

vtable это не хеш таблица... Не более чем массив функций. У варианта другие преимущества

[KirillVelichk0]

Действительно, был не прав, по факту везде vtables используется. Но, возможно я ошибаюсь, мы в любом случае не можем гарантировать константный O(1), вызов vtalbes может занять дополнительные расходы?

[KirillVelichk0]

Так, ладно, в баню производительность. std::variant будет очевидно шустрее виртуальных методов, но я боюсь наврать лишний раз.
Ну, вообще, так как полиморфизм внешний, можно навесить достаточно большое количество дополнительных методов работы с хранимыми данными. Для виртуальных методов мы так не можем. Если использовать указатели на функции и просто передавать в них void*, то проблема будет примерно та же (надеюсь, я вас правильно понял)

[Ritan]

Вместо std::arrray<char, ...> лучше std::aligned_storage_t использовать с максимальным для всех типов align

[Kelbon]

это устаревшее и нет, не лучше( про алигмент написал выше)

[Ritan]

Любопытно, упустил, что aligned_storage объявили устаревшим.

Аргументация там имхо хромает: aligned_storage требует использования reinterpret_cast, поэтому используйте alignas(align) std::byte[size], который требует того же самого.

Опять объявляют что-то устаревшим так как не смогли что-то сделать не ломая ABI, поэтому решили сломать API

[Kelbon]

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

[Ritan]

Он более ясно выражает цель - получить какой-то объём хранилища с указанным алайментом. И мне не важно, что под капотом там alignas(align) char data[size], alignas(align) std::byte data[size] или вообще struct { char pad[pad_size], char data[size] }.

Так ведь можно и std::array задепрекейтить, тоже можно(почти) заменить на сишные массивы

[voldemar_d]

Читал, что есть библиотеки, которые работают с контейнерами, имеющими явные методы begin и end - они могут работать с std::array, а с сишными массивами не могут.

[Ritan]

Это вина библиотек - использовать рекомендуют свободные функции std::begin(c), std::end(c), а не методы

[voldemar_d]

Это понятно, что это их вина, но тем не менее.

[Kelbon]

байты с align более чем ясно дают понять что происходит, по итогу получается, что aligned_storage только добавлял мороки и вероятность ошибиться лишний раз

array действительно хотелось бы задепрекейтить, точнее улучшить встроенный массив, добавив ему копирование и пару методов (begin/end/data), но к сожалению это легаси и этого никто делать не собирается

[Ritan]

улучшить встроенный массив, добавив ему копирование и пару методов (begin/end/data),

Это сломает совместимость с большой кучей сишного кода, так что не нужно

[AndreyVelichko]

Маладэс