Staticly Bound Member Function Pointers

I've been thinking lately and I have to say I'm a little bit mad with the standard concerning member function pointers. Since the standard accounts for both virtual and nonvirtual member function pointers as being the same type and forces dynamic binding on virtual functions, one of two possibilities comes to mind in terms of how the compiler would handle such a "problem":

Either the compiler's version of member function pointers has to store two values -- a vtable offset/pointer union (assuming they are using a vtable for polymorphism), and a value representing whether the function is virtual or nonvirtual (which wouldn't be very efficient in terms of memory use and forces a check whenever it's dereferenced), or the compiler creates a table for nonvirtual function pointers as well as for virtual, just for the sake of member function pointers, so that they can be accessed and stored in the same way as virtual member functions. The function pointer table could be stored "behind" the start of the vtable (sort of like how data is usually stored "behind" a dynamically allocated array for the purpose of deallocation).

But that brings me to my point. If the latter is true, then that means that when you use a member function pointer to call a nonvirtual member function, it is forcibly dynamically bound! I know it's not something that's extremely taxing, but it is taxing none-the-less. I checked sizeof( void(a::*)() ) on msvc++ 6.0 and it is returning 4, which in this case is the exact same amount of bytes needed for a pointer to a "regular" datatype (IE int, float, void), so unless they are doing something that I'm not thinking of, then they are forcing dynamic binding on functions where it is not necissary. I've never exactly made a compiler, so I can't say I've given this an extreme amount of thought, but as of now, I don't see any other way to do this without having to use more than sizeod(void*) for the data.

I'm not saying I disagree with msvc++, as theirs is the best approach that I can think of, but what I am saying is that I think the standard needs a minor adjustment. Perhaps I'm being a bit too concerned, but there is a solution I've come up with that I don't see any problems with:


--------------------

2 datatypes for member function pointers:

a datatype for both virtual and nonvirtual member functions (this is the standard implementation as it is now, and still is obviously necissary)

AND

a datatype that forces static binding on member functions (IE, a syntactical variant on standard function pointers)

--------------------


The purpose of this is both speed and memory occupancy. Why account for dynamic binding where you have no virtual functions or specifically want to force static binding of a parent version of the class rather than the child version? If you comply to the standard, then the latter isn't even possible!!!

It just doesn't make sense to me why they wouldn't account for such possibilities. Member function pointers are not used extremely often, but they still are used. I've come into a situation where the former problem exists and it angred me to find out there was no way of handling it. I'm sure I'm not the only one who has come accross this limitation of the language. I just don't understand why they thought such functionality wouldn't be useful. :confused:

Any insight?

Hmmm...This isn't really a question per se so I guess I can just add my two cents. First off all pointers are the same size

Code:

---

sizeof(int(*)(void *, void *, int, int, int)) == sizeof(int *)

---

Although you do bring up some interesting points I have found that the longer you program the more little issues like this come up in practice (not just speculation). And the more of that these little issues come up the more you find yourself understanding why the standard is written as it is.

Quote:

---

Originally posted by master5001
First off all pointers are the same size

---

Wrong.

Code:

---

class a;
cout << sizeof( void (a::*)() ) << endl;
cout << sizeof( void * ) << endl;

---

Complie this in CodeWarrior and you get the following output:

Code:

---

12
4

---

>>Complie this in CodeWarrior and you get the following output:

My guess is that this is sizeof() doing more work than you are asking....I think its saying that that function pointer uses 3 pointers to operate....not that that pointer itself takes up 12 bytes.....

If so, it all depends on how you define pointer.

If it's just a memory address, then, yes, the function pointer is probably three pointers

(and it is)

But fact remains, the (pointer to a member function) is 12 bytes long.

Quote:

---

Originally posted by Sang-drax
If so, it all depends on how you define pointer.

If it's just a memory address, then, yes, the function pointer is probably three pointers

(and it is)

But fact remains, the (pointer to a member function) is 12 bytes long.

---

Curiously, a member func pointer has a sizeof of 4 for VC++6!!!

And 8 under Mingw!!!!

Quote:

---

Originally posted by master5001
First off all pointers are the same size

---

Actually, you are wrong there. C++ makes the specific exception for member function pointers because they have to account for polymorphism, which cannot be done by a single pointer.

In terms of the codewarrior example, sizeof was NOT doing something extra. The member function "pointer" actually does take up that amount of space for the compiler. The standard is very lax on member function pointer implementation and so it is perfectly fine. They just chose not to create member function pointers in the same way the mscv++ 6.0 does it.

That's pretty ridiculous. Why would they set it up like that? Surely they were concerned about speed? There must be some other reason then. :confused:

If you're refering to why member function pointers are not "pointers" in the regular sense of the word, it's because of virtual functions. In fact, that makes it slower.

If you mean why does code warrior have 3 times more space needed for member function "pointers" than msvc++, then speed is the only thing I can think of, but I doubt that the speed difference is significant enough to account for making the data required 3 times larger.

Quote:

---

Originally posted by Sebastiani
That's pretty ridiculous. Why would they set it up like that? Surely they were concerned about speed? There must be some other reason then. :confused:

---

I would just like to state that although my codewarrior's sizeof() returned 12, it produced the same assembler for the actual call as VC++ (loading the stack address of the object into a register and then issuing the call)...just a matter of interpretation I guess

Interesting. Actually, I was confused. I thought the poster was implying that ALL compilers forced dynamic binding on pfn's to non-virtual members. But having reread it, I see it's optional. Luckily for me, my compiler uses 12 bytes per pfn. :D

That's just an opinion. Personally, I'd much rather have just 4 bytes in memory rather than 12, even if it means forced dynamic binding, especially considering there are still going to be some checks that have to be made in the 12 byte version to check if the function is virtual or not.

Anyways, this is the reason I posted. Both situations can happen, but often times you only need a literal member function pointer (like a function pointer). That would resolve any issues and give more control to the programmer on a separate level from the way the compiler is implemented.

Trade speed for size? No way. Just how many pfn's could you have anyway? Even 1000 would add a mere 8K to your exe.

It depends on what you're optimizing for. Speed isn't always what you're trying to optimize. And it's not a simple matter of speed vs space. It's an unbelievably small (almost not noticeable) amount of speed, vs 3 times the amount of space. You can say that 12 bytes isn't a lot, but it's the ratio that matters!

Yes well I would argue that dynamic is probably ~1/3 as fast as static bound pfn's. That could really hurt a loop brother.

Quote:

---

Originally posted by Polymorphic OOP
It depends on what you're optimizing for. Speed isn't always what you're trying to optimize. And it's not a simple matter of speed vs space. It's an unbelievably small (almost not noticeable) amount of speed, vs 3 times the amount of space. You can say that 12 bytes isn't a lot, but it's the ratio that matters!

---

As I said, in my 2 examples with the most varying results for sizeof on a member function pointer (VC++6 - 4, Codewarrior 5 - 12), both compilers produced the same code to call the function.....they both loaded the address for the object into a register and then issued the call - same amount of code upto the actual function declarations!

Also both cases were in debug mode without any real optimisation...

Personally I wouldnt get too hung up on the sizeof returned from these function pointers.........

Quote:

---

Polymorphic OOP
Junior Member

Registered: Nov 2002
Location: Redmond, WA
Posts: 6

---

Me is thinking something... :)

Quote:

---

Originally posted by golfinguy4
Me is thinking something... :)

---

Hmm?

Redmond, Washington... home of ________

I read your profile though so it seems I am wrong.

Quote:

---

Originally posted by Fordy
As I said, in my 2 examples with the most varying results for sizeof on a member function pointer (VC++6 - 4, Codewarrior 5 - 12), both compilers produced the same code to call the function.....they both loaded the address for the object into a register and then issued the call - same amount of code upto the actual function declarations!

Also both cases were in debug mode without any real optimisation...

Personally I wouldnt get too hung up on the sizeof returned from these function pointers.........

---

By the way you're describing it this sounds as though you are saying that member function pointers are just a single call based on an actual pointer to a memory location. That would not account for polymorphism!

Unless you are leaving out where it's getting the address of the function from by accident, this can't be true. The only explanation for what you're saying is that the compilers are noticing you are only using nonvirtual member functions and they internally implement them just as function pointers. Try the example you gave but use virtual member functions instead and call that member function through the pointer on different derivations of the base class. It can't possibly just go by single function pointer because that varies dependng on the object. It has to go through the vtable. If it didn't, then the same exact function would be called every time, which is against the standard.

EDIT: Another explanation can be that it's a single function pointer, but not directly to the member function. The function it points to would have to call the appropriate function. The problems with this is that it'd be referring to a function that has to be implicitly created by the compiler, and it means that every time the member function is called it has to go through a pointer, which would be pretty much being doing the same thing -- dynamic binding on functions meant to be statically bound, plus, it also forces yet another step of dereferencing for ones that are meant to be dynamically bound. So that doesn't really get anywhere.

I highly doubt that codewarrior would make sizeof return 12 unless it actually does take up that amount, simply because, in this case, they have absolutely no reason to. Even with struct padding, compilers have sizeof return the size that it actually takes up in memory. They're not going to give a false value just for the heck of it. It makes operations that deal with memory locations a hassle because the programmer would have a false view of what's going on, and in this case, just liek with padding, it really does matter. If you really want to check, make an array of 2 member function pointers, take their individual addresses, type cast the "pointers to pointer to member function" to "pointers to char" (which should be a valid cast, though I'd have to check), then subtract one from the other. I'm willing to bet it will give you the result of whatever sizeof returned.

I guess the problem is that most of this is just educated guessing as to how they "probably" implement it and not exactly how they do. It's probably documented somewhere, so if anyone has links then post them.

Quote:

---

Originally posted by golfinguy4
Redmond, Washington home of

---

... nintendo, microsoft, digipen???

take your pic... :D i know the answer

Quote:

---

Another explanation can be that it's a single function pointer, but not directly to the member function.

---

This doesn't appear to be the case in release builds on VC.net. Based on the following -

Code:

---

class a
{
public:
        void fun()
        {
                //
        }

};

typedef  void (a::*amemfun)();

int main()
{
        a ins;
        amemfun e = a::fun;
       
        (ins.*e)();       
       

        return 0;
}

---

The relevant call in main is -

Code:

---

00401006  mov        dword ptr [ebp-4],offset a::fun (401020h)
0040100D  lea        ecx,[ebp-5]
00401010  call        dword ptr [ebp-4]

---

The member function begins at 401020h -

Code:

---

?fun@a@@QAEXXZ:
00401020  push        ebp

---

So it's not a jump into a table.

Altering fun to a virtual function produces the code -

Code:

---

0040100E  mov        dword ptr [ebp-4],offset `vcall' (401060h)
00401015  lea        ecx,[ebp-8]
00401018  call        dword ptr [ebp-4]

---

at 401060h is (the virtual table) -

Code:

---

??_9@$BA@AE:
00401060  mov        eax,dword ptr [ecx]
00401062  jmp        dword ptr [eax]

---

which then jumps to the correct function.

So based on this it would appear that it is determined at compile time whether the function pointer is to be used on non virtual functions on VC.net.

That's exactly my point. The only way that the compiler is going to be able to do that is through optimizations at compile time!

The point is, it can't always make these optimizations. Of course, if you make a pointer to a member function and store the address of a member function to it in the same function, it's going to be able to adjust itself to either just make it like a "literal" function pointer, and if it's a virtual function it's going to know it just the same.

The only way you can really test is:

Make a function that has a parameter of a member function pointer. Within the function, call the member function on a particular object. The object should be dereferenced through a pointer that's either global or local to a class. Assign to the object pointer a derived version of the class somewhere in another function. This way, the function that calls the member function will not be able to know the datatype of the object and it won't know if the function is virtual or non virtual.

Call that function with both a virtual member function pointer and a nonvirtual in the same program.

That makes it impossible for the function to make the optimization of using a literal pointer. It would have no way of knowing at compile time which type of pointer will be stored, and the function would have to account for all cases -- virtual and nonvirtual for the datatype and all of its children.

Quote:

---

Of course, if you make a pointer to a member function and store the address of a member function to it in the same function, it's going to be able to adjust itself to either just make it like a "literal" function pointer

---

Does it matter where the pointer is declared? If I did

class a
{
public:
void fun(){}
};

class b : public a
{
public:
void fun(){}
};

Depending on my function pointer type, I've still got to point it at either

a::fun

or

b::fun

How is attempting to disguise the object type going to fool the compiler. Assuming fun is non-virtual it is clear which function is being called as the function has been assigned to the pointer. I'm not entirely sure what you're getting at (perhaps you could provide an example), but you can't assign the address of a bound member function to a pointer.

The following code, assigns the address in the same way, and calls the member function directly -

Code:

---

class a
{
public:
        void fun()
        {       
        }

};

class b : public a
{
        void fun()
        {
        }
};

typedef  void (a::*amemfun)();

a* ga;

void foo(amemfun amf)
{
       

        ((*ga).*amf)();       
}

void bar()
{
        ga = new b;
}


int main()
{

       
    bar();       

        amemfun amf = a::fun;

        foo(amf);

        delete ga;

        return 0;
}

---

Quote:

---

Originally posted by JoeSixpack
How is attempting to disguise the object type going to fool the compiler. Assuming fun is non-virtual it is clear which function is being called as the function has been assigned to the pointer.

---

Why? For the same reason that a virtual function is called through static binding when using a object -- not through a pointer. If you declare a member function pointer, initialize it to a constant, and use it in the same function, the compiler is going to see this and just make the optimization of calling it statically. The only way you can truly check what's happening is if you can make the compiler oblivious to what's going on until runtime.

Just think logically about your example. If the pointer, as defined by the standard has to account for both static and dynamic binding, it can't possibly just call the function without making any other checks, because it is possible that the function is either virtual or nonvirtual! The only possible way it can just use a literal pointer is if the compiler itself noticed that you were using a nonvirtual function.

If you want to be 100% sure, make a static link library function that returns a pointer to a member function. That way it is completely impossible for the function which uses that return value to make the optimization because they aren't related until linking.

EDIT: Another thing you can try is declaring them all as volatile so that the compiler can't make any assumptions.

Quote:

---

If you want to be 100% sure, make a static link library function that returns a pointer to a member function. That way it is completely impossible for the function which uses that return value to make the optimization

---

Why would the optimisation be done in the caller? When the library is compiled it'll do the same checks. If you're using a compiler that checks whether it's using 'addresses' of virtual or non-virtual functions, it could just return the 'address' of the member function if it's non-virtual. The library will have access to the same information about the class as the exe. The caller may be the only one that knows the exact object in an inheritance hierachy but if you're returning a pointer to a specific member function either it can use it or not (which the compiler will be able to deduce from the return type).

Quote:

---

Another thing you can try is declaring them all as volatile so that the compiler can't make any assumptions.

---

What assumptions is the compiler making? It can see the class declaration so it knows whether it contains virtual members or not.

Quote:

---

Originally posted by JoeSixpack
[B]Why would the optimisation be done in the caller? When the library is compiled it'll do the same checks.[B]

---

Because when used in the program which links to the library, it only sees the header during the compilation, so during compile time, that program has no way of knowing if it's returning a pointer to a virtual or nonvirtual member. If it's done in the same compiliation, however, it's possible that it can see this and interpret the "member to function pointer" as a more specific type.

Quote:

---

What assumptions is the compiler making? It can see the class declaration so it knows whether it contains virtual members or not.

---

It's not a matter of whether or not it knows that the class has virtual functions or not, it's a matter of "Is it calling one of the virtual functions or is it calling one of the nonvirtual functions." Just because one function is virtual doesn't mean they all are, so the compiler still has to account for both cases. Both types have completely different calling conventions, so if it just said "this class has some virtual functions, I have to use a vtable offset" it would either have to use an offset for nonvirtual functions as well, or do any of the other things I mentioned. The one thing that it physically can NOT do without optimizations is call the function directly without making a check, explicitly through data in the member function "pointer," or through a nested function call. If it didn't, then it would have no way of accounting for both cases.

Well, I think Joe pretty much provided a concrete answer on how a certain compiler handled the matter. Even Fordy's tests on CodeWarrior gave the same results, leading me to believe this may be the norm, which is a relief!

Question: what does the lea instruction do anyway?

Quote:

---

Originally posted by Sebastiani
Question: what does the lea instruction do anyway?

---

Load Effective Address (I think anyway)

Loads a memory offset into a register.....like a C pointer

Quote:

---

Because when used in the program which links to the library, it only sees the header during the compilation, so during compile time, that program has no way of knowing if it's returning a pointer to a virtual or nonvirtual member.

---

I'm not exactly on the ball with C++ at the moment, but don't you have to specify whether a function is virtual in the declaration? Therefore the information will be in the header?

Quote:

---

It's not a matter of whether or not it knows that the class has virtual functions or not, it's a matter of "Is it calling one of the virtual functions or is it calling one of the nonvirtual functions." Just because one function is virtual doesn't mean they all are, so the compiler still has to account for both cases.

---

Yes but surely the compiler can tell from the class declaration if a function is one of the virtual members. It can see the declaration in all compilation units. It's not making any assumptions.

The only way I can see that this would be an issue (although I may be being blind), is if you can take the address of a bound member function. In which case it wouldn't be possible at compile time to determine it's exact type. However, as this illegal I can't figure out how it would be possible to hide the fact from a compiler that a function was virtual.

Quote:

---

Question: what does the lea instruction do anyway?

---

As Fordy states plus it is used in this case to implicity pass the 'this' pointer into a member function via a register (ecx).