[32] Pointers to member functions
(Część C++ FAQ Lite, Copyright © 1991-2002, Marshall Cline, cline@parashift.com)

FAQ - sekcja [32]:

[32.1] Is the type of "pointer-to-member-function" different from "pointer-to-function"?

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:

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

[ Góra | Dół | Poprzednia sekcja | Następna sekcja | Szukaj w FAQ ]

[32.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.

[ Góra | Dół | Poprzednia sekcja | Następna sekcja | Szukaj w FAQ ]

[32.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.

[ Góra | Dół | Poprzednia sekcja | Następna sekcja | Szukaj w FAQ ]

[32.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.

[ Góra | Dół | Poprzednia sekcja | Następna sekcja | Szukaj w FAQ ]

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

[Recently made it clearer there is an and between the recommended typedef and macro (in 9/02). Click here to go to the next FAQ in the "chain" of recent changes.]

Do both a typedef and a #define macro.

Step 1: create 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);

Step 2: create a #define macro:

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

(Normally I dislike #define macros, but you should use them with pointers to members because they improve the readability and writability of that sort of code.)

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.

[ Góra | Dół | Poprzednia sekcja | Następna sekcja | Szukaj w FAQ ]

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

[Recently made it clearer there is an and between the recommended typedef and macro (in 9/02). Click here to go to the next FAQ in the "chain" of recent changes.]

Use both the typedef and the #define macro described earlier, and you're 90% done.

Step 1: create 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);

Step 2: create a #define macro:

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

Now your array of pointers-to-member-functions is straightforward:

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

And your usage of one of the member function pointers is also 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.

[ Góra | Dół | Poprzednia sekcja | Następna sekcja | Szukaj w FAQ ]

E-Mail E-mail the author
[ C++ FAQ Lite | Spis treści | Skorowidz | O autorze | © | Pobierz swoją własną kopię ]
Ostatnia aktualizacja Jun 17, 2002
Wersja polska: 0.1h Oct 3, 2003