A study of C + + pointers (iii) member function pointers

The C language pointer is quite flexible, but it is also quite easy to make mistakes. Many C-language beginners, even the C-language veteran, are apt to stumble under the C-language pointer. But there is no denying that the position of the pointer in the C language is extremely important, perhaps to a radical point: the C program without pointers is not a real C program.

But the C + + pointer often gives me a feeling of being shackled. C + + has more stringent static types than C, more emphasis on type safety, and emphasis on compile-time checks. Therefore, for the C language is the most easily wrong pointers, but also can not let go: C + + pointer is divided into data pointers, data member pointers, function pointers, member function pointers, and can not easily convert to each other. and the declaration formats of these pointers are different:

A more important difference is that the space the pointer occupies is different. Even in a 32-bit system, the space may be 4 bytes, 8 bytes, 12 bytes, or even 16 bytes, which varies greatly depending on the platform and compiler.

Although C + + still has a universal pointer void*, but it belongs to the object of being denounced, and can no longer "omnipotent." It cannot be converted into a member pointer.

As a result, the C + + pointer becomes awkward: we need a pointer that can point to the same type of data, whether it's regular or member data; we need a pointer that can point to a function of the same type, whether it's a static function or a member function. But none, at least from the current C + + standard, has not been seen.

Since we've got classes, we've started to organize data structures in a way that we can work with, and since we've got a template, we've started separating the data from the algorithms so we can reuse them. But no matter how toss, now most functions are no longer single, are married to the class, into the siege. But we still need to be able to call these member functions freely.

Consider a timed call under Windows. The prototype of the SetTimer function is this:

UINT_PTR SetTimer(
　　　 HWND hWnd,
　　　 UINT_PTR nIDEvent,
　　　 UINT uElapse,
　　　 TIMERPROC lpTimerFunc
);

Where the parameters are not explained, this function is expected to be known by most Windows developers. Lptimerfunc is a function pointer that will be called periodically. If we do not trigger timers by wm_timer messages, but by Lptimerfunc, then we can only use ordinary functions or static functions, and we cannot use member functions in any case, even through static function transfers.

Consider the creation of the thread again:

uintptr_t _beginthread(
　　 void( *start_address )( void * ),
　　 unsigned stack_size,
　　 void *arglist
);

Start_address still only supports normal functions. But this is good, it allows the callback function to be a void* parameter, and it will invoke the start_address as a arglist parameter. So the smart C + + programmer, using arglist to pass the this pointer, uses the static function to successfully invoke the member function:

class mythread
{
　 public:
　　　 static void doit(void* pThis)
　　　 {
　　　　((mythread*)pThis)->doit();
　　　 }
　　　 void doit(...){}
};

main()
{
　 ...
　 mythread* pmt = new mythread;
　 _beginthread(&mythread::doit, 0, (void*)pmt);

　 ...
}