Thread: Staticly Bound Member Function Pointers

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.

Originally posted by golfinguy4
Redmond, Washington home of

... nintendo, microsoft, digipen???

take your pic... i know the answer

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.

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;
}

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.

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).

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.

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?

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?

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.

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).