On Thu, Nov 14, 2024 at 4:51 PM Jason McKesson wrote:
>
> On Thu, Nov 14, 2024 at 6:42 AM Frederick Virchanza Gotham wrote:
> >
> > The C++ programming language is held back by the
> > Microsoft compiler's implementation of VTables.
>
> This statement requires evidence which you have not provided. You
> provide no evidence that most, or even many, C++ programmers need the
> thing you're talking about. The fact that you personally want it and
> can imagine how others might find it useful is not evidence that it is
> actually useful to C++ programmers.
>
> Since that's the very foundation of your idea, it should be dismissed
> on the basis of that alone.



Remember a few months ago I started talking about 'interceptor" functions:

     https://lists.isocpp.org/std-proposals/2024/07/10577.php

And then I started a draft paper:

    http://www.virjacode.com/papers/interceptor.htm

And then earlier this month I started intercepting method calls (i.e.
the invocation of class member functions):

    https://godbolt.org/z/79xjs6so1

So let's take about intercepting virtual methods. Whenever a virtual
method is invoked, then the 'this' pointer will be in the first
position (so that's the RDI register on 64-Bit x86 Linux, or the RCX
register on 64-Bit x86 MS-Windows, or at "stack-pointer + 4" on 32-Bit
x86). If we know that the method being invoked is virtual, then that
means that the RDI register holds the address of a polymorphic object,
and so if we know that the polymorphic object has its VTable pointer
at offset 0, then we can consult the VTable to determine the type of
the object (and we can also cast it to the most-derived object). If
you look at the above GodBolt link, you'll see on Line # 116 how I get
the type_info from a "void*" pointer -- but this isn't possible on the
Microsoft compiler because the VTable pointer might be somewhere other
than at offset 0.