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