Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c++ > #84196

Re: Function pointer size (was Re: nullptr is not 0)

Show all headers | View raw

On 5/19/2022 10:36 AM, Richard Damon wrote:
>>>
>>> Yes that sort of describes the problem. The pointer to member needs 
>>> to be able to refer to a virtual function, or even a function that is 
>>> a member of a virtual base class, and handling that sort of stuff is 
>>> what forces the extra memory in the pointer-to-member.
>>
>> That's incorrect in general. Again, using x86 as a counterexample:
>>
>> Implementations that use different representations for virtual vs. 
>> non-virtual member pointers (GCC, Clang) manage to stuff that extra 
>> information into the "original" memory - they use the lowest bit of 
>> the pointer as a flag.
>>
>> Implementations that use identical representations for virtual vs. 
>> non-virtual member pointers (MSVC) naturally don't have this issue at 
>> all.
>>
>> So, no, the need to handle virtual functions does not require extra 
>> memory in pointer-to-member function.
> 
> But not all processors have a LSB to use for that sort of flag.
> 
> Some have instructions that can be at any address, because the 
> instruction set has single byte opcodes (They could just force all 
> functions to be at addresses with lower order zeros, but that is wasteful)
> 
> Others, like the ARM, use the low order bit to indicate which 
> instruction set the function is written in, so it isn't available for 
> such a use.
> 
> Thus, there sometimes IS a need for an additional flag bit to indicate 
> if the pointer is an index into the v-table or the actual address of the 
> function.

Well, that's a completely different claim. "Sometimes", huh...

Firstly, as MSVC implementation demonstrates that the flag is not 
necessary at all.

Secondly, quite possibly it is the case "sometimes". However, one might 
argue that if the implementation had to increase pointer size just for 
the sake of that single flag, it would probably abandon that approach 
altogether and switch to MSVC-like approach, which requires no flag.

>>
>>> I remember seeing documentation in one compiler that gave options for 
>>> "optimizations" where you could limit what sort of member functions 
>>> you could take the address of to make the pointers smaller. Omitting 
>>> the handling of Virtual Base classes, or those and virtual functions 
>>> (I forget if there was some other level).
>>
>> Well, you forget.
>>
>> These optimizations have absolutely nothing to do with virtual 
>> functions. They have everything to do with the hierarchy structure. 
>> They depend on the answer to one question: is it necessary to correct 
>> the `this` pointer value when making a call?
> 
> Not to my knowledge. That adjustment tends to be done by a "Thunk" to 
> correct the base address of "this" for non-first base classes. 

No, no, no. That cannot be done by a thunk. The adjustment value is a 
run-time value, which changes as you convert the pointer up and down the 
hierarchy.

Theoretically, it can be probably implemented somehow by a bunch of 
thunks and a heap of compiler magic: say, by generating as many 
different thunks as there are different correction values. But I haven't 
seen any real-life implementations that do that. And it seems unreasonable.

GCC, Clang and MSVC store the `this` correction offset inside the 
pointer. That is exactly why in these compilers the pointer takes two 
words instead of one.

>> Correction to `this` might be necessary in case of multiple 
>> inheritance, in case of virtual inheritance and in some other niche 
>> cases. This correction is what the extra memory in pointer-to-member 
>> function stores. This is why pointer-to-member-function is larger than 
>> an ordinary pointer.
>>
>> But it has nothing to do with calls to virtual functions.
>>
> 
> Nope, because the pointer-to-member function pointer has no idea of the 
> type of the object that it will be used on, so CAN'T store the full 
> offset. (That is the job of the Thunk).

This is completely incorrect.

(Once again, let me reiterate that what I'm stating here is not offered 
for debate. These are hard facts about how modern implementations work. 
This is learning material for those willing to learn.)

The pointer has to store the _delta_ value that corrects the `this` 
pointer between the static pointer type and the dynamic type of the 
pointed object.

Here's a little illustrative sketch

    struct B {};
    struct D : /* some other bases */, B { void foo() {} };
    // Base subobject `B` is offset inside `D`

    void (B::*pf)() = static_cast<void (B::*)()>(&D::foo);
    // Here the upper word of `pf` will store the correction
    // delta, which is needed to down-convert `B *` to `D *`

    D *pd = new D;
    B *pb = pd;
    // `pb` is not the same numerically as `pd`

    (pb->*pf)();
    // Correctly calls `D::foo`
    // Before the actual call value of `pb` is adjusted by the
    // correction delta stored in `pf`, thus providing us with
    // the proper `D *this` pointer

    (pd->*pf)();
    // Correctly calls `D::foo`
    // Since `pf` is declared as `void (B::*)()`, the `pd` is
    // first converted to `B *` (offsetting it), and then
    // adjusted by the correction value stored in `pf`
    // (un-offsetting it). This results in `pd` again, which
    // is the proper `D *this` pointer

As you can see in the example above, even though it "has no idea of the 
type of the object that it will be used on", everything works out nicely 
and correctly.

> But it may be needed for a pointer-to-member function pointer which 
> doesn't always hold the address of the member function to call but 
> sometimes an offset/index into the vtable.
> 
> As an example:
> 
> class B {
> public:
>              void f1();
>      virtual void f2();
> }
> 
> class D : public B {
> public:
>      virtual void f2();
> }
> 
> we take the member-function-pointers
> 
> void (B::*ptr1)() = &B::f1;
> void (B::*ptr2)() = &B::f2;
> 
> 
> B b;
> D d;
> 
> b*->ptr1() vs b *->ptr2() vs d*->ptr1() vs d*->ptr2()
> 
> There is a need to know that the "value" stored in ptr1 is the actual 
> address of B:f1(), while ptr2 is storing an offset into the vtable of B 
> for the member function.
> 
> ptr2 can NOT just have the address of B::f2() as if derived class D 
> overrides f2(), then the call via ptr2 needs to go to D::f2().

Nobody says that `ptr2` has to store address of `B::f2()`. But your 
claim that there is a need to distinguish between `ptr1 and `ptr2` at 
run-time is incorrect.

This is what MSVC will translate your example into:

   class B {
   public:
             void f1();
     virtual void f2();
             void f2_thunk() { return f2(); }
   };

   class D : public B {
   public:
     virtual void f2();
   }

   ...
   void (B::*ptr1)() = &B::f1;
   void (B::*ptr2)() = &B::f2_thunk;

   B b;
   D d;

   //b*->ptr1() vs b *->ptr2() vs d*->ptr1() vs d*->ptr2()

And suddenly everything works correctly, like magic! No need "to know" 
which pointer is virtual and which pointer is not. Very simple.

Again, in this case `f2_thunk` takes advantage of the already 
implemented virtual dispatch mechanism. The pointer simply re-uses it, 
instead of re-implementing it.

It is quite possible that GCC's approach is more efficient, despite 
being more bulky: branch predictions, cache behavior and so on... But 
there's no denying that MSVC's approach is far more elegant.

-- 
Best regards,
Andrey

Back to comp.lang.c++ | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

nullptr is not 0 Sam <sam@email-scan.com> - 2022-05-08 09:45 -0400
  Re: nullptr is not 0 "Alf P. Steinbach" <alf.p.steinbach@gmail.com> - 2022-05-08 16:21 +0200
  Re: nullptr is not 0 Andrey Tarasevich <andreytarasevich@hotmail.com> - 2022-05-08 10:00 -0700
  Re: nullptr is not 0 Bonita Montero <Bonita.Montero@gmail.com> - 2022-05-09 06:38 +0200
  Re: nullptr is not 0 Juha Nieminen <nospam@thanks.invalid> - 2022-05-09 05:06 +0000
    Re: nullptr is not 0 Vir Campestris <vir.campestris@invalid.invalid> - 2022-05-09 21:46 +0100
      Re: nullptr is not 0 Andrey Tarasevich <andreytarasevich@hotmail.com> - 2022-05-09 13:57 -0700
        Re: nullptr is not 0 Juha Nieminen <nospam@thanks.invalid> - 2022-05-10 05:04 +0000
          Re: nullptr is not 0 Andrey Tarasevich <andreytarasevich@hotmail.com> - 2022-05-09 22:33 -0700
      Re: nullptr is not 0 scott@slp53.sl.home (Scott Lurndal) - 2022-05-09 21:56 +0000
        Function pointer size (was Re: nullptr is not 0) Vir Campestris <vir.campestris@invalid.invalid> - 2022-05-17 21:30 +0100
          Re: Function pointer size (was Re: nullptr is not 0) scott@slp53.sl.home (Scott Lurndal) - 2022-05-17 21:00 +0000
            Re: Function pointer size (was Re: nullptr is not 0) Vir Campestris <vir.campestris@invalid.invalid> - 2022-05-19 21:52 +0100
            Re: Function pointer size (was Re: nullptr is not 0) Andrey Tarasevich <andreytarasevich@hotmail.com> - 2022-05-19 14:08 -0700
          Re: Function pointer size (was Re: nullptr is not 0) Andrey Tarasevich <andreytarasevich@hotmail.com> - 2022-05-17 17:05 -0700
          Re: Function pointer size (was Re: nullptr is not 0) Juha Nieminen <nospam@thanks.invalid> - 2022-05-18 04:46 +0000
            Re: Function pointer size (was Re: nullptr is not 0) Andrey Tarasevich <andreytarasevich@hotmail.com> - 2022-05-18 02:14 -0700
              Re: Function pointer size (was Re: nullptr is not 0) Juha Nieminen <nospam@thanks.invalid> - 2022-05-19 14:53 +0000
                Re: Function pointer size (was Re: nullptr is not 0) "Alf P. Steinbach" <alf.p.steinbach@gmail.com> - 2022-05-19 17:19 +0200
                Re: Function pointer size (was Re: nullptr is not 0) Andrey Tarasevich <andreytarasevich@hotmail.com> - 2022-05-19 10:14 -0700
                Re: Function pointer size (was Re: nullptr is not 0) Richard Damon <Richard@Damon-Family.org> - 2022-05-19 13:45 -0400
                Re: Function pointer size (was Re: nullptr is not 0) Andrey Tarasevich <andreytarasevich@hotmail.com> - 2022-05-19 11:31 -0700
                Re: Function pointer size (was Re: nullptr is not 0) Juha Nieminen <nospam@thanks.invalid> - 2022-05-20 06:58 +0000
                Re: Function pointer size (was Re: nullptr is not 0) Andrey Tarasevich <andreytarasevich@hotmail.com> - 2022-05-20 00:11 -0700
                Re: Function pointer size (was Re: nullptr is not 0) Richard Damon <Richard@Damon-Family.org> - 2022-05-19 12:27 -0400
                Re: Function pointer size (was Re: nullptr is not 0) Andrey Tarasevich <andreytarasevich@hotmail.com> - 2022-05-19 09:47 -0700
                Re: Function pointer size (was Re: nullptr is not 0) Richard Damon <Richard@Damon-Family.org> - 2022-05-19 13:36 -0400
                Re: Function pointer size (was Re: nullptr is not 0) Andrey Tarasevich <andreytarasevich@hotmail.com> - 2022-05-19 11:24 -0700
                Re: Function pointer size (was Re: nullptr is not 0) Richard Damon <Richard@Damon-Family.org> - 2022-05-19 21:32 -0400
                Re: Function pointer size (was Re: nullptr is not 0) Andrey Tarasevich <andreytarasevich@hotmail.com> - 2022-05-19 20:28 -0700
                Re: Function pointer size (was Re: nullptr is not 0) Richard Damon <Richard@Damon-Family.org> - 2022-05-20 10:57 -0400
                Re: Function pointer size (was Re: nullptr is not 0) Andrey Tarasevich <andreytarasevich@hotmail.com> - 2022-05-19 09:35 -0700
                Re: Function pointer size (was Re: nullptr is not 0) Andrey Tarasevich <andreytarasevich@hotmail.com> - 2022-05-19 10:10 -0700
                Re: Function pointer size (was Re: nullptr is not 0) Juha Nieminen <nospam@thanks.invalid> - 2022-05-20 07:15 +0000
          Re: Function pointer size (was Re: nullptr is not 0) "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2022-05-18 11:50 -0700
            Re: Function pointer size (was Re: nullptr is not 0) Andrey Tarasevich <andreytarasevich@hotmail.com> - 2022-05-18 15:46 -0700
              Re: Function pointer size (was Re: nullptr is not 0) "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2022-05-19 20:52 -0700

csiph-web