pointer to function and typedefs

I'm not sure if I can understand the use of a typedefs in the pointers to functions context.

Code:

int (*ptrFunc)(int, double);
ptrFunc = myFunction;

and

Code:

typedef int (*ptrFunc)(int, double);
ptrFunc test = myFunction;

I can see that the typedef allowed me to declare several objects of the type ptrFunc. That is nice. But...

The use of typedef here confuses me since this is not the same as the usual typedef type identifier syntax.

Also it seems that typedef here is (shock!) defining a new type (of pointer to a function that returns an int and takes an int and a double as parameters), something that I didn't think typedef could do. It could create a synonym for a type, not define one.

Am I missing some logic that would probably help me understand better why typedef behaves in this way? Also, is it common usage for a typedef to be used in this context, or do pointers to functions rarely need it since there is rarely the need to point to a different function, once the pointer is initialized?

1. It is normal that typedef behaves this way because this is what it was meant to do. typedef defines a name to be associated to a certain type. In this case, the type is int(*)(int, double) (I think this is how MSVC++ puts it) and the name is ptrFunc.

2. Yes, it is common use. I know for sure that the Quake engine uses (or used) massively this feature. Quite a few functions were passed a typedef'ed pointer to function called 'use'.

Another common use is when using DLLs for plug-ins. You could very well store pointer to functions retrieved in the DLL and keep them in an object. For instance, you could have an object of a Plugin class that would have defined a WMHandlerPtr pointer to function that would be defined as bool (*) (HWND, UINT, WPARAM, LPARAM) and another FooPtr that would be defined otherwise.

Using the same example, you could say that one might want to unload a DLL and load another one (a different graphics engine for an emulator, for example). You would then already have your GraphicsDLL object created; therefore, you'd want to have an UnloadDLL() and a LoadDLL() functions. You would have to reinitialize all your pointer to functions

Interesting...

Another possible use I can see for them is for FSMs (the AI sort). I was always plagued with cluttered and hard to maintain classes when trying to create these under Visual Basic. I think I can see some grounds for improvement if I use pointers to functions.

Thanks Desolation. Now I just need to go easy on this. Just reading about functions that return pointers to functions... the syntax is a killer.

It isn't if you wisely use typedefs. You would just have to consider it as a new type without thinking too much about the fact it's a pointer to function.

Remember, though, the syntax may be weird, but the concept is the same as regular pointers. Functions are stored in memory addresses just like variables and a pointer to a function holds the address of the function it points to. Dereferencing it and passing it appropriate parameters will do the same as using the function directly.

Code:

typedef bool (*WMHandlerPtr) (HWND, WPARAM, LPARAM);

bool Plugin::GetWMHandlerPtr(const char* func_name) {
    myHandler = (WMHandlerPtr) GetProcAddress(myModule, func_name);
    return (myHandler == 0);
}

void Plugin::OnLButtonDown(HWND hwnd, WPARAM wprm, LPARAM lprm) {
    try {
        if(myHandler == 0)
            throw("OnLButtonDown");
        (*myHandler)(hwnd, wprm, lprm);
    } catch(const char* func) {
        if(!GetWMHandlerPtr(func))
            throw();
    }
}

I coded this on the fly and I thought maybe I'd add a little error checking but I'm not too sure about the code. It should be something like this, though.

I normally avoid using typedef just to give a pointer a new name, since it hides rather more information than is good for you. A whole new name to hide a single * isn't worth it IMO.

However, function pointers are much hairier beasts, with a rather odd-looking syntax all of their own (at first).
A single function pointer on it's own is one thing, but when you start combining it with other things, your code suddenly looks like lisp

And when you get into pointers to class member functions - OMG is the phrase of the day.

http://www.newty.de/fpt/index.html