Why the size of a pointer to a function is different from the size of a pointer to a member function?

帅比萌擦擦* 提交于 2019-11-27 20:04:52

EDIT: So I noticed I'm still getting votes on this months later, even though my original answer is bad and misleading (I can't even remember what I was thinking at the time, and it doesn't make a lot of sense!) so I thought I'd try and clarify the situation, as people must still be getting here through search.

In the most normal situation, you can pretty much think of

struct A {
    int i;
    int foo() { return i; }
};

A a;
a.foo();

as

struct A {
    int i;
};
int A_foo( A* this ) { return this->i; };

A a;
A_foo(&a);

(Starting to look like C, right?) So you would think the pointer &A::foo would just be the same as a normal function pointer. But there are a couple of complications: Multiple inheritance, and virtual functions.

So imagine we have:

struct A {int a;};
struct B {int b;};
struct C : A, B {int c;};

It might be laid out like this:

As you can see, if you want to point to the object with an A* or a C*, you point to the start, but if you want to point to it with a B* you have to point somewhere in the middle.

So if C inherits some member function from B and you want to point to it then call the function on a C*, it needs to know to shuffle the this pointer. That information needs to be stored somewhere. So it gets lumped in with the function pointer.

Now for every class that has virtual functions, the compiler creates a list of them called a virtual table. It then adds an extra pointer to this table to the class (vptr). So for this class structure:

struct A
{
    int a;
    virtual void foo(){};
};
struct B : A
{
    int b;
    virtual void foo(){};
    virtual void bar(){};
};

The compiler might end up making it like this:

So a member function pointer to a virtual function actually needs to be an index into the virtual table. So a member function pointer actually needs 1) possibly a function pointer, 2) possibly an adjustment of the this pointer, and 3) possibly a vtable index. To be consistent, every member function pointer needs to be capable of all of these. So that's 8 bytes for the pointer, 4 bytes for the adjustment, 4 bytes for the index, for 16 bytes total.

I believe this is something that actually varies a lot between compilers, and there are a lot of possible optimizations. Probably none actually implements it the way I've described.

For a lot of detail, see this (scroll to "Implementations of Member Function Pointers").

Basicly because they need to support polymorphic behavior. See a nice article by Raymond Chen.

Some explanations may be found here : The underlying representation of member function pointers

Although pointers to members behave like ordinary pointers, behind the scenes their representation is quite different. In fact, a pointer to member usually consists of a struct containing up to four fields in certain cases. This is because pointers to members have to support not only ordinary member functions, but also virtual member functions, member functions of objects that have multiple base classes, and member functions of virtual base classes. Thus, the simplest member function can be represented as a set of two pointers: one holding the physical memory address of the member function, and a second pointer that holds the this pointer. However, in cases like a virtual member function, multiple inheritance and virtual inheritance, the pointer to member must store additional information. Therefore, you can't cast pointers to members to ordinary pointers nor can you safely cast between pointers to members of different types. Blockquote

I'd guess it has something to do with this pointer... That is, each member function must also have the pointer for the class they are in. The pointer then makes the function a bit bigger in size.

Some of the main reasons for representing pointers to member functions as {this, T (*f)()} are:

  • It has simpler implementation in the compiler than implementing pointers to member functions as T (*f)()

  • It does not involve runtime code generation nor additional bookkeeping

  • It performs reasonably well compared to T (*f)()

  • There isn't enough demand from C++ programmers for the size of pointers to member functions to be equal to sizeof(void*)

  • Runtime code generation during execution is de-facto a taboo for C++ code currently

易学教程内所有资源均来自网络或用户发布的内容,如有违反法律规定的内容欢迎反馈
该文章没有解决你所遇到的问题?点击提问,说说你的问题,让更多的人一起探讨吧!