Is is not about, whether it can be done, but whether the C++ standard would be the right place for it.   Another topic is about interface ownership. Even if the internal Microsoft memory format can be reverse-engineered and would currently work in a stable way, you codify it into an international standard. That is not nice, you are taking away Microsoft's ownership over their ABI.   Giuseppe cited an ISO rule that no AI generated texts are allowed in ISO standards. So auto-generation of code is out of the picture - apart from that one would not trust AI for something as important (and undocumented with few examples the AI could have learned from). Reverse engineering Microsoft code and putting that code (possibly back-converted into C/C++) into the standard could also make problems for some jurisdictions - I believe it is more accepted in Europe for interoperability and less in the US. If people go that route then typically you would work with two isolated teams, one team reverse-engineering the interface, the other team writing their own code from that interface description. To make sure that code or knowledge of copyrighted code was not directly transferred.   -----Ursprüngliche Nachricht----- Von:Frederick Virchanza Gotham via Std-Proposals <std-proposals_at_[hidden]> Gesendet:Fr 30.05.2025 15:57 Betreff:Re: [std-proposals] Standard support for different ABI‘s for class vtables An:std-proposals <std-proposals_at_[hidden]>; CC:Frederick Virchanza Gotham <cauldwell.thomas_at_[hidden]>;   On Friday, May 30, 2025, Andre Kostur wrote: I doubt it.  The Standard doesn’t mandate a “vtable pointer” either.  Neither does it talk about any of the other ABI things (other than linkage, and even then doesn’t say much about that either).  This would seem to be entirely a discussion for the compiler vendors.    There wouldn't have to be any mention of vtables -- only a stipulation that a standard-compliant compiler shall have a feature that it can emit code as follows:          int IExaminer_Microsoft::GetStatus(void)         {             // Adjust the vtable pointer for Microsoft:             char unsigned const *const pobj = static_cast<char unsigned*>(static_cast<void*>(p));             typedef int (*FuncPtr)(IExaminer*);             FuncPtr *const vtable = static_cast<FuncPtr*>( static_cast<void*>( pobj + 4 ) );             return vtable[3]( this->p ); // GetStatus is the 4th entry in the vtable         }  In fact I bet you within a week or so I could write a program that would do this purely from reverse-engineering Microsoft machine code. I would write a function as follows and feed it into the Microsoft compiler:      int Func(IExaminer *const p)     {         return p->GetStatus();     }  then compile it and disassemble it to a handful of instructions something like:      mov rax, rcx ; Copy object pointer to rax     add rax, 4 ; Move to the vtable pointer (offset 4)     mov rax, [rax] ; Dereference to get vtable pointer     add rax, 24 ; Move to 4th virtual function (3 * 8 bytes)     mov rax, [rax] ; Dereference to get function pointer     jmp rax ; Jump to function  It would be easy to turn the the above 6 instructions into C code, similar to how I figured out how to devirtualise member function pointers in the following unfinished unpublished paper, see the section on the implementation for Microsoft:      http://www.virjacode.com/devirtualize.html <http://www.virjacode.com/devirtualize.html>  It wouldn't be much work at all to code this -- an AI could figure out most of it.