I think the kind of problem you are probably trying to solve has already an idiomatic solution to it: "Factory Method".


Also if you want to reassign the virtual functions dynamically, there is already a way to do this built-in the language: just reassign (reset) a pointer to base with a pointer to some derived type; and this will dynamically change the current vptr table to which the original pointer to base refered to:
```cpp
std::unique_ptr<Animal> v{new Mammal};

// v refers to Mammals vptr

v = unique_ptr<Animal>{new Bird};

// v refers to Bird vptr

```



Julien Villemure

Get Outlook for Android<https://aka.ms/AAb9ysg>
________________________________
From: Std-Proposals <std-proposals-bounces_at_[hidden]> on behalf of Frederick Virchanza Gotham via Std-Proposals <std-proposals_at_[hidden]>
Sent: Monday, August 1, 2022 7:16:15 AM
To: std-proposals <std-proposals_at_[hidden]>
Cc: Frederick Virchanza Gotham <cauldwell.thomas_at_[hidden]>
Subject: Re: [std-proposals] Versatility -- Classes change at runtime

On Sun, Jul 31, 2022 at 2:57 PM Jason McKesson via Std-Proposals
<std-proposals_at_[hidden]> wrote:

> > > Compiler options are out of scope in this list. If you just want a compiler
> > > extension, make a suggestion to the implementations you care about.
>>
> > Well then we should discuss whether this should change.
>
> Um... no. Absolutely not.
>
> C++ is a *language*; the details of how you call a particular program
> to process that language are out of scope for the language itself.
> Those details are not unimportant to the process of developing that
> language, but they are ultimately not part of what C++ is.


This is a minor technicality. It's like saying that cars manufacturers
like Honda have nothing at all to do with tyres -- even though every
car gets 4 tyres.

There was a time when people said "C++ doesn't know anything about
threads", and we changed that to reflect reality.

The C++ Standard already acknowledges the existence of a compiler and
how it should behave (e.g. issue a diagnostic), and so it wouldn't be
a big deal for the Standard to say that we can specify options to the
compiler (since we're all doing that already anyway).


> We already have problems with compiler switches making C++ code
> non-portable (compiler-specific features) or non-interoperable (if
> library X is built against certain switches, you must build your
> application with those switches to use it). We don't want to encourage
> this with special language features that only work via compiler
> options.


The real world is already like this though. "-pthread" is just one
example. Part of the evolution of the C++ Standard is observing how
people in the real world are working with the Standard as it changes.

--
Std-Proposals mailing list
Std-Proposals_at_[hidden]
https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals