[30] Pointers to member functions
(Part of C++ FAQ Lite, Copyright © 1991-2000, Marshall Cline, cline@parashift.com)

FAQs in section [30]:

[30.1] Is the type of "pointer-to-member-function" different from "pointer-to-function"? UPDATED!

[Recently changed another "It's" to "Its" thanks to Chris Young (on 3/00). Click here to go to the next FAQ in the "chain" of recent changes.]

Yep.

Consider the following function:

 int f(char a, float b);

The type of this function is different depending on whether it is an ordinary function or a non-static member function of some class:

  • Its type is "int (*)(char,float)" if an ordinary function
  • Its type is "int (Fred::*)(char,float)" if a non-static member function of class Fred

Note: if it's a static member function of class Fred, its type is the same as if it was an ordinary function: "int (*)(char,float)".

[ Top | Bottom | Previous section | Next section ]

[30.2] How do I pass a pointer to member function to a signal handler, X event callback, etc?

Don't.

Because a member function is meaningless without an object to invoke it on, you can't do this directly (if The X Windows System was rewritten in C++, it would probably pass references to objects around, not just pointers to functions; naturally the objects would embody the required function and probably a whole lot more).

As a patch for existing software, use a top-level (non-member) function as a wrapper which takes an object obtained through some other technique (held in a global, perhaps). The top-level function would apply the desired member function against the global object.

E.g., suppose you want to call Fred::memberFunction() on interrupt:

 class Fred {
 public:
   void memberFunction();
   static void staticMemberFunction();  // A static member function can handle it
   // ...
 };
 
 // Wrapper function uses a global to remember the object:
 Fred* object_which_will_handle_signal;
 void Fred_memberFunction_wrapper()
 {
   object_which_will_handle_signal->memberFunction();
 }
 
 int main()
 {
   /* signal(SIGINT, Fred::memberFunction); */   // Can NOT do this
   signal(SIGINT, Fred_memberFunction_wrapper);  // OK
   signal(SIGINT, Fred::staticMemberFunction);   // Also OK
 }

Note: static member functions do not require an actual object to be invoked, so pointers-to-static-member-functions are type compatible with regular pointers-to-functions.

[ Top | Bottom | Previous section | Next section ]

[30.3] Why do I keep getting compile errors (type mismatch) when I try to use a member function as an interrupt service routine?

This is a special case of the previous two questions, therefore read the previous two answers first.

Non-static member functions have a hidden parameter that corresponds to the this pointer. The this pointer points to the instance data for the object. The interrupt hardware/firmware in the system is not capable of providing the this pointer argument. You must use "normal" functions (non class members) or static member functions as interrupt service routines.

One possible solution is to use a static member as the interrupt service routine and have that function look somewhere to find the instance/member pair that should be called on interrupt. Thus the effect is that a member function is invoked on an interrupt, but for technical reasons you need to call an intermediate function first.

[ Top | Bottom | Previous section | Next section ]

[30.4] Why am I having trouble taking the address of a C++ function?

This is a corollary to the previous FAQ.

Long answer: In C++, member functions have an implicit parameter which points to the object (the this pointer inside the member function). Normal C functions can be thought of as having a different calling convention from member functions, so the types of their pointers (pointer-to-member-function vs. pointer-to-function) are different and incompatible. C++ introduces a new type of pointer, called a pointer-to-member, which can be invoked only by providing an object.

NOTE: do not attempt to "cast" a pointer-to-member-function into a pointer-to-function; the result is undefined and probably disastrous. E.g., a pointer-to-member-function is not required to contain the machine address of the appropriate function. As was said in the last example, if you have a pointer to a regular C function, use either a top-level (non-member) function, or a static (class) member function.

[ Top | Bottom | Previous section | Next section ]

[30.5] How can I avoid syntax errors when calling a member function using a pointer-to-member-function? UPDATED!

[Recently added the "macros are sometimes useful" paragraph at the end (on 3/00). Click here to go to the next FAQ in the "chain" of recent changes.]

Two things: (1) use a typedef, and (2) use a #define macro.

Here's the way you create the typedef:

 class Fred {
 public:
   int f(char x, float y);
   int g(char x, float y);
   int h(char x, float y);
   int i(char x, float y);
   // ...
 };
 
 // FredMemberFn points to a member of Fred that takes (char,float)
 typedef  int (Fred::*FredMemberFn)(char x, float y);

Here's the way you create the #define macro (normally I dislike #define macros, but this is one of those rare cases where they actually improve the readability and writability of your code):

 #define callMemberFunction(object,ptrToMember)  ((object).*(ptrToMember))

Here's how you use these features:

 void userCode(Fred& fred, FredMemberFn memFn)
 {
   callMemberFunction(fred,memFn)('x', 3.14);
   // Would normally be: (fred.*memFn)('x', 3.14);
 }

I strongly recommend these features. In the real world, member function invocations are a lot more complex than the simple example just given, and the difference in readability and writability is significant. comp.lang.c++ has had to endure hundreds and hundreds of postings from confused programmers who couldn't quite get the syntax right. Almost all these errors would have vanished had they used these features.

Note: #define macros are evil in 4 different ways: evil#1, evil#2, evil#3, and evil#4. But they're still useful sometimes. But you should still feel a vague sense of shame after using them.

[ Top | Bottom | Previous section | Next section ]

[30.6] How do I create and use an array of pointers to member functions? UPDATED!

[Recently added the "macros are sometimes useful" paragraph at the end (on 3/00). Click here to go to the next FAQ in the "chain" of recent changes.]

Use the usual typedef and #define macro and you're 90% done.

First, use a typedef:

 class Fred {
 public:
   int f(char x, float y);
   int g(char x, float y);
   int h(char x, float y);
   int i(char x, float y);
   // ...
 };
 
 // FredMemberFn points to a member of Fred that takes (char,float)
 typedef  int (Fred::*FredMemberFn)(char x, float y);

That makes the array of pointers-to-member-functions straightforward:

 FredMemberFn a[4] = { &Fred::f, &Fred::g, &Fred::h, &Fred::i };

Second, use the callMemberFunction macro:

 #define callMemberFunction(object,ptrToMember)  ((object).*(ptrToMember))

That makes calling one of the member functions on object "fred" straightforward:

 void userCode(Fred& fred, int memberFunctionNum)
 {
   // Assume memberFunctionNum is between 0 and 3 inclusive:
   callMemberFunction(fred, a[memberFunctionNum]) ('x', 3.14);
 }

Note: #define macros are evil in 4 different ways: evil#1, evil#2, evil#3, and evil#4. But they're still useful sometimes. Feel ashamed, feel guilty, but when an evil construct like a macro improves your software, use it.

[ Top | Bottom | Previous section | Next section ]

E-Mail E-mail the author
[ C++ FAQ Lite | Table of contents | Subject index | About the author | © | Download your own copy ]
Revised Jul 10, 2000