Why doesn't C++ have a pointer to member function type?

Question

I could be totally wrong here, but as I understand it, C++ doesn\'t really have a native \"pointer to member function\" type. I know you can do tricks with Boost and mem_fu

Answer 1

The issue is surely not the basics of having an object pointer and a function pointer in one easy-to-use package, because you could do this using a pointer and a thunk. (Such thunks are already used by VC++ on x86 to support pointers to virtual member functions, so that these pointers only take up 4 bytes.) You might end up with a lot of thunks, it's true, but people already rely on the linker to eliminate duplicate template instantiations -- I do, anyway -- and there's only so many vtable and this offsets you'll end up with in practice. The overhead would probably not be significant for any reasonably-sized program, and if you don't use this stuff then it won't cost you anything.

(Architectures that traditionally use a TOC would store the TOC pointer in the function pointer part, rather than in the thunk, just as they would have to do already.)

(This new type of object would not be exactly substitutable for a normal pointer to function, of course, because the size would be different. They would, however, be written the same at the call point.)

The problem that I see is that of the calling convention: supporting pointers to functions this way might be tricky in the general case, because the generated code would have to prepare the arguments (this included) the same way without regard to the actual type of thing, function or member function, to which the pointer points.

This is probably not a big deal on x86, at least not with thiscall, because you could just load ECX regardless and accept that if the calling function doesn't need it then it will be bogus. (And I think VC++ assumes ECX is bogus in this case anyway.) But on architectures that pass arguments for named parameters in registers to functions, you may end up with a fair amount of shuffling in the thunk, and if stack arguments are pushed left-to-right then you're basically stuffed. And this can't be fixed up statically, because in the limit there's no cross-translation-unit information.

[Edit: MSalters, in a comment to rocketmagnet's post above, points out that if both object AND function are known, then the this offset and so on can be determined immediately. This totally didn't occur to me! But, with this in mind, I suppose there need only be stored the exact object pointer, maybe offset, and the exact function pointer. This makes thunks totally unnecessary -- I think -- but I'm pretty sure that the issues of pointing to member functions and non-member functions alike would remain.]