Hi Frederick,     standardizations like compiler command-line options were in my humble observation totally outside of the scope of the standard in the past. Now there is the SG15 Tooling subgroup focusing on refactoring tools in the narrow sense, but everything from build systems, packing up to IDEs in the wider sense.   Besides the standardization of certain compiler options, there would be the possibility to automatically generate/translate compatible sets for every compiler.   https://lists.isocpp.org/mailman/listinfo.cgi/sg15   However, I think C++ features, which need compiler options, especially lists of classes, are the wrong direction. Currently compilers (in the sense from running them from the command line) have the sense of translation units, not of classes. What if different translation units would compile the used classes with different flags? C++ libraries would not only distribute header files and the compiled libraries, but also lists of command line options?     About modifying vtables   Currently, the standard not even prescribes that vtables are used for implementing dynamic polymorphism at all.   A hack for modifying those vtables would either have to standardize the usual / the typical use of vtables as mandatory for each C++ implmentation, or you would have to document all properties of vtables you want to be able to change in an abstract way, so that the C++ language could provide the options for those changes in a second step and still not mention vtables at all in the standard.     IIRC one of the answers (which I cannot find now) to your post mentioned it in passing. There are projects/ideas to implement dynamic polymorphism without native vtables, but with the other existing C++ features. Like creating a vtable which lives as member within the classes and can be accessed.   I would research those projects on your part and think about whether they could benefit from additional support (e.g. syntax sugar) from the standard. Advantages would be that it would not be a hack, it could be fully customized, it would be strictly opt-in, it would be specified in translation units instead of on the command line, there is an existing momentum and use cases for those projects.   Best, Sebastian   -----Ursprüngliche Nachricht----- Von:Frederick Virchanza Gotham via Std-Proposals <std-proposals_at_[hidden]> Gesendet:Mo 01.08.2022 23:56 Betreff:Re: [std-proposals] Versatility -- Classes change at runtime An:std-proposals <std-proposals_at_[hidden]>; CC:Frederick Virchanza Gotham <cauldwell.thomas_at_[hidden]>; On Mon, Aug 1, 2022 at 3:11 PM Thiago Macieira via Std-Proposals <std-proposals_at_[hidden]> wrote: > Unless you're aiming at getting negative chance of getting your proposal > through, I suggest you decouple compiler options from it. I don't actually have a use case for my "proposal".   <-- they're scare quotes I can't think of a good use off-hand for being able to modify v-tables at runtime. This is all just a thought experiment -- which I believe is needed to keep discussion lubricated. We can get really comfortable with ideas like "object-orientated" and "polymorphism", and how they apply to C++, but irrespective of how comfortable we ever become, I think we should always be throwing out wild and wacky ideas just to get people's creative juices flowing. In the year 2070, the idea of a 'class' might be quite similar to what it is today. But then again, someone might come up with a mad idea that nobody had fathomed -- and maybe even everyone will baulk at it at first -- but our previous ideas of polymorphism might begin to seem very limited when we explore the new idea. If discussion about adding compiler options to the Standard opens up new doors of creativity in people's minds, and brings forth new strange ideas, then let's talk about it. I want to evaluate weird, odd, strange ideas and see where it takes us -- even if it's talk about editing v-tables at runtime (with atomic pointers in writeable memory). Can anyone reading this post right now think of a very good use for standardised compiler options? P.S. In a previous post a day or two ago, I shared some code that malfunctioned when compiled with -O2 or -O3 (however it worked fine with -O1). Today I was tinkering with it more and I got it to work properly at ever optimisation level by simply changing the v-table pointer from "void *" to "void volatile *". -- Std-Proposals mailing list Std-Proposals_at_[hidden] https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals