Date: Tue, 2 Aug 2022 11:49:48 +0100
Sebastian Wittmeier wrote:
> 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?
This happens already. In my last job I had to investigate a bug
whereby a library was compiled with "-fshort-enums" but the main
program wasn't. It malfunctioned on big-endian machines but not on
little-endian machines.
> C++ libraries would not only distribute header files and the compiled libraries, but also lists of command line options?
YES! I hadn't thought of this, but it would be very good. For
closed-source libraries, there can be more than one binary provided
(but only if it's worthwhile of course).
> 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.
The syntax I proposed for editing the v-table does not assert that
v-tables exist. I just proposed changing the method used as follows:
virtual MyClass::MyMethod = &SomeOtherMethod;
so there's no need to talk about v-tables in the Standard.
> 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?
This happens already. In my last job I had to investigate a bug
whereby a library was compiled with "-fshort-enums" but the main
program wasn't. It malfunctioned on big-endian machines but not on
little-endian machines.
> C++ libraries would not only distribute header files and the compiled libraries, but also lists of command line options?
YES! I hadn't thought of this, but it would be very good. For
closed-source libraries, there can be more than one binary provided
(but only if it's worthwhile of course).
> 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.
The syntax I proposed for editing the v-table does not assert that
v-tables exist. I just proposed changing the method used as follows:
virtual MyClass::MyMethod = &SomeOtherMethod;
so there's no need to talk about v-tables in the Standard.
Received on 2022-08-02 10:50:01