Generic function pointers

[helios]

So, according to this: http://www.safercode.com/blog/2008/11/25/generic-function-pointers-in-c-and-void.html
GFPs are void(*)(void).
I tried this:

typedef void (*gfp)(void);

gfp f(int a){
	return (gfp)f;
}

int main(){
    return 0;
}

This compiles, but if I comment the cast to 'gfp', MinGW complains about conversion to void(*)(). So, is 'gfp' generic, or just a regular pointer to a function that returns and takes nothing? If the latter, what are (if there are any) generic function pointers in C++?

[Duthomhas]

There is no such thing as a generic function pointer. C and C++ specifically prohibit type compatability between function pointers.

The example in that link is dangerous. Sure it worked fine for the writer, and it may work fine for you or me. But for someone, somewhere, will want to force feed you your computer down your throat when the program you wrote gives them the BSOD.

See The Function Pointer Tutorials for all you need to know.
http://www.newty.de/fpt/


Fortunately, in C++ we have functors, which are just as good (well, better) than function pointers. The FPT link has a good section on functors.

Hope this helps.

[helios]

Good thing I didn't try to use that. Not that I really needed to, I was just curious after playing around with DLLs/shared objects and learning about the restriction of casting between code and data pointers.

So why is it so dangerous, anyway? Also, does the dangerousness change between platforms, or is it so random that it changes between systems?

[Duthomhas]

Every time you call a function, there is an associated calling convention and a function stack frame (also know as an activation record).

Both are machine, compiler, and language-dependent. The caller and the callee must agree on which arrangement to use before any transaction can occur. Mix any of it up and failure results or can result.

In this case, the default calling convention for C is cdecl, meaning that the caller pushes the function arguments onto the stack, calls the function, and after the function returns the caller cleans-up the stack to its previous state.

The caller thinks that it is calling a function taking no arguments and returning nothing.
The callee thinks that there should be an int sitting on the stack, and that it should return a pointer.
That's a whole can of worms just waiting to break out of the Peanut Brittle.

Here's more reading for you.

Wikipedia stuff :-J
http://en.wikipedia.org/wiki/Calling_convention
http://en.wikipedia.org/wiki/Call_stack

The Old New Thing: What can go wrong when you mismatch the calling convention?
http://blogs.msdn.com/oldnewthing/archive/2004/01/15/58973.aspx
http://blogs.msdn.com/oldnewthing/archive/2004/01/16/59415.aspx

Well, that's enough fun for now...

Enjoy. :-]

[helios]

Wow. I had no idea Windows did so much clean up behind the scenes. IMO, it would be better to crash the program while reporting what the error was.

[Duthomhas]

LOL. That's why we do things for hysterical raisons. XD

[firedraco]

Ugh. That kind of stuff really annoys me...someday I need to make a wrapper (or a compilier) that if it sees stuff like void main() it gives you an error "You or your code book is retarded. Please fix the issue before you continue coding."

[Bazzy]

That kind of stuff really annoys me...someday I need to make a wrapper (or a compilier) that if it sees stuff like void main() it gives you an error "You or your code book is retarded. Please fix the issue before you continue coding."

gcc -Werror=main