Я все еще не понимаю задачу оборачивания полиморфной сущности в С. Обычно когда закручивают оптимизации, подход примерно следующий: мы шаблонами делаем всё, что можем (и интерфейсы у нас концепты), после чего стираем тип (тут не избежать динамического полиморфизма в одной из форм) только когда создание объекта начинает завязываться на неизвестные при компиляции данные. В этом плане если есть какой-то PackageBaseAdapter<PackageBase> то стирание делается обычно уже для PackageBaseAdapter

Я обновил пример псевдокода. добавил пару виртульных функций в Packagebase

Тут вот очень грубо идея в том, что вообще никогда не возникает конструкция nonvirtual(object.virtual())

Потому что object.virtual() это запрос фактического типа object, этот запрос неизбежен, а значит должен быть выполнен как можно раньше

Половина понятно а половина нет. Ну нам же надо как-то хранить абстрактный тип данных в любом случае. Пользователь должен иметь возможно записть в контейнер объект. В свою очередь контейнер должен иметь возможность вызать для любого объекта две функции size и weight. Не очень понимаю как это через адаптер сделать. И проще ли будет?

Сам объект P1 или P2 должен физически находиться в контейнере. Не проалоцирован где-то в куче и передан по указателю или объявлен статически а именно в контейнере. Сами объекты P1 и P2 имеют конструкторы с динамическими параметрами. Ну т.е. в моем понимании move в контейнер практически неизбежен (если не заморачиваться с какими-нибудь хитрыми паттернами)

Мы храним абстрактный тип данных, но, если возможно, хранить абстрактно контейнер в виде C<P1> : CBase предпочтительнее, чем оборачивать P1 : PackageBase в C - так понятнее?

P1018R2: Evolution status after San Diego 2018 (by Ville Voutilainen) (2018-11-10) (Related: GitHub issue)

P1041R3: Make char16_t/char32_t string literals be UTF-16/32 (by R. Martinho Fernandes) (2019-01-21) (Related: GitHub issue)

P1115R0: Improving the Return Value of Erase-Like Algorithms II: Free erase/erase if (by Marc Mutz) (2019-06-17) (Related: GitHub issue)

P1132R1: out_ptr - a scalable output pointer abstraction (by JeanHeyd Meneide, Todor Buyukliev, Isabella Muerte) (2018-08-11) (Related: GitHub issue)

P1136R0: 2018-09 Bellevue ad-hoc meeting information (by Herb Sutter) (2018-06-21)

P1306R0: Expansion statements (by Andrew Sutton, Sam Goodrick, Daveed Vandevoorde) (2018-10-08) (Related: GitHub issue)

P1341R0: Unifying Asynchronous APIs in the Standard Library (by Lewis Baker) (2018-11-25) (Related: GitHub issue)

P1386R1: A Standard Audio API for C++: Motivation, Scope, and Basic Design (by Guy Somberg, Guy Davidson, Timur Doumler) (2019-03-11) (Related: GitHub issue)

P1478R2: Byte-wise atomic memcpy (by Hans Boehm) (2019-08-05) (Related: GitHub issue)

P1505R1: Mandating the Standard Library: Clause 31 - Atomic operations library (by Daniel Sunderland) (2019-06-16) (Related: GitHub issue)

P1525R1: One-Way execute is a Poor Basis Operation (by Eric Niebler, Kirk Shoop, Lewis Baker, Lee Howes, Gašper Ažman, Corentin Jabot, Tomasz Kamiński, Zach Laine, Ville Voutilainen) (2020-10-15) (Related: GitHub issue)

P1723R0: Mandating the Standard Library: Clause 31 - Atomics library (by Marshall Clow) (2019-06-17) (Related: GitHub issue)

P1768R0: Contiguous Containers Should Contain .data() (by Nevin Liber) (2019-06-17) (Related: GitHub issue)

P1788R0: Reuse of the built modules (BMI) (by Olga Arkhipova) (2019-06-17) (Related: GitHub issue)

P1845R0: 2019-09-21 Denver Tooling Meeting (by Bryce Adelstein Lelbach, Jon Kalb) (2019-08-06) (Related: GitHub issue)

P1860R0: C++ Networking Must Be Secure By Default (by JF Bastien, Alex Christensen) (2019-10-07) (Related: GitHub issue)

P1874R1: Dynamic Initialization Order of Non-Local Variables in Modules (by Michael Spencer) (2019-11-12) (Related: GitHub issue)

P1897R2: Towards C++23 executors: A proposal for an initial set of algorithms (by Lee Howes) (2020-01-13) (Related: GitHub issue)

P1982R0: Rename link to time_zone_link (by Howard Hinnant) (2019-11-25) (Related: GitHub issue)

P1998R1: Simple Facility for Lossless Integer Conversion (by Ryan McDougall) (2020-01-08) (Related: GitHub issue)

Чуть более. Т.е. предложение сделать C шаблонный? по типу объекта который он хранит? Но тогда у нас имплементаций C будет нагенерировано много...

Более широкий вопрос. Надо внимательно посмотреть на того, кто собирается использовать С. Почему выполняется set_package, а не присваивание C? Почему сравнивается с PackageBase, а не C?

Когда выполняется is_package, что это на самом деле за проверка, если бы C знал фактический тип P1, а не PackageBase?

хм..

Согласен, возможно не достаточно входных данных дал. C используется “глобально” или почти глобально на программу. Контейнер С на самом деле кроме хранения делает еще кучу вещей и более того работает с прерываниям контроллера. Поэтому он должен быть фактически как синглтон.

Сиглтоны обычно выглядят как интерфейсы (наборы сишных функций) без данных

Да, фактически надо узнать тип. ну т.е. is_package(P1<2,4>) было бы достаточно. просто узнать тип

Он распространяется в готовом для сборки виде с "easy-build" батником.  
Сначала требуется настроить среду и подготовить edk2: с этим я разобрался. А дальше идёт обращение к vcvars32.bat...
Провернуть то же самое с VsDevCmd.bat не удалось

да. это не синглтон конечно. тем более есть случаи когда таких контейнеров в системе может быть больше одного

я поэтому про variant и подумал

А пакеты P1, P2, Pn пишуться “пользователем”. именно поэтому (как мне кажется0) им нужен  интерфейс. может конечно есть какие-то еще варианты

Ну тогда для C<P1<2, 4>> это вопрос о сравнении его динамического типа и C<P1<2, 4>> и для этого можно не включать RTTI если он выключен - достаточно там

struct CBase {
   virtual const char* type_handle() const = 0;
};
template <typename T>
class C : public CBase {
    static constexpr char * name() {
         return __FUNCTION__;
    }
    const char* type_handle() const override {
        return name();
    }
};