Comments on: Generic Function Pointers In C And Void * http://www.safercode.com/blog/2008/11/25/generic-function-pointers-in-c-and-void.html Making Your Code Faster, Stronger, Safer… Thu, 18 Feb 2010 05:11:26 +0000 http://wordpress.org/?v=2.9.1 hourly 1 By: Nonce http://www.safercode.com/blog/2008/11/25/generic-function-pointers-in-c-and-void.html#comment-3479 Nonce Fri, 22 Jan 2010 21:16:43 +0000 http://www.safercode.com/blog/2008/11/25/generic-function-pointers-in-c-and-void.html#comment-3479 You didn't actually mention what systems have a difference sized void and function pointer in C. What systems are these? OS/400? VAX/VMS? I've never heard of such a system. You didn’t actually mention what systems have a difference sized void and function pointer in C. What systems are these? OS/400? VAX/VMS? I’ve never heard of such a system.

]]> By: Shantanu Goel http://www.safercode.com/blog/2008/11/25/generic-function-pointers-in-c-and-void.html#comment-193 Shantanu Goel Tue, 24 Feb 2009 10:54:16 +0000 http://www.safercode.com/blog/2008/11/25/generic-function-pointers-in-c-and-void.html#comment-193 @Sean: I don't think that would be portable because data and function pointer sizes might differ on different architectures and might lead to truncation of the address and information once lost in such a case (by using void * for a function pointer) can not be recovered by the trick that you mentioned. @Sean: I don’t think that would be portable because data and function pointer sizes might differ on different architectures and might lead to truncation of the address and information once lost in such a case (by using void * for a function pointer) can not be recovered by the trick that you mentioned.

]]> By: Sean http://www.safercode.com/blog/2008/11/25/generic-function-pointers-in-c-and-void.html#comment-188 Sean Mon, 23 Feb 2009 19:53:11 +0000 http://www.safercode.com/blog/2008/11/25/generic-function-pointers-in-c-and-void.html#comment-188 Another way to get a function pointer from a void * is to cast your function pointer to a void ** and dereference it. Lame example below. int call_fp_from_vp(void *vp) { int (*fp)(int); *(void **)(&fp) = vp; return fp(0); } Another way to get a function pointer from a void * is to cast your function pointer to a void ** and dereference it. Lame example below.

int call_fp_from_vp(void *vp)
{
int (*fp)(int);

*(void **)(&fp) = vp;

return fp(0);
}

]]> By: guruwars http://www.safercode.com/blog/2008/11/25/generic-function-pointers-in-c-and-void.html#comment-31 guruwars Fri, 02 Jan 2009 00:42:11 +0000 http://www.safercode.com/blog/2008/11/25/generic-function-pointers-in-c-and-void.html#comment-31 In C or just a simple unit type case, union is a good choice, but in C++, with complex type would not be preferred because of wasting of memory. At big size structure, how about using inheritance, i think. In C or just a simple unit type case, union is a good choice, but in C++, with complex type would not be preferred because of wasting of memory. At big size structure, how about using inheritance, i think.

]]> By: Shantanu Goel http://www.safercode.com/blog/2008/11/25/generic-function-pointers-in-c-and-void.html#comment-13 Shantanu Goel Tue, 02 Dec 2008 07:38:21 +0000 http://www.safercode.com/blog/2008/11/25/generic-function-pointers-in-c-and-void.html#comment-13 @Vikas: Yes, M1 needs to know the exact prototype while caling it, hence it needs to know it either statically or through some macro mumbo-jumbo (can't do it through enums). The advantage here is that the registration api remains constant, and the actual calling part, which is anyways dependent on the type of module, will typecast it appropriately before calling. (Think of a layer that interacts with various drivers to collect events from them and provide different notifications to upper layers) About far, it has many issues, as in the function being called may not actually be far, using this will unnecessarily complicate things for the compiler and your programs will slow down. There won't be any type checking as well. And most importantly, far is non-standard, so you can't even rely on it while moving from one compiler/platform to another. @Vikas: Yes, M1 needs to know the exact prototype while caling it, hence it needs to know it either statically or through some macro mumbo-jumbo (can’t do it through enums). The advantage here is that the registration api remains constant, and the actual calling part, which is anyways dependent on the type of module, will typecast it appropriately before calling. (Think of a layer that interacts with various drivers to collect events from them and provide different notifications to upper layers)
About far, it has many issues, as in the function being called may not actually be far, using this will unnecessarily complicate things for the compiler and your programs will slow down. There won’t be any type checking as well. And most importantly, far is non-standard, so you can’t even rely on it while moving from one compiler/platform to another.

]]> By: Vikas http://www.safercode.com/blog/2008/11/25/generic-function-pointers-in-c-and-void.html#comment-11 Vikas Tue, 25 Nov 2008 19:11:38 +0000 http://www.safercode.com/blog/2008/11/25/generic-function-pointers-in-c-and-void.html#comment-11 Hmm....I am still not sure how would M1 get to know the version of the callback to call. I mean suppose M2 passes a callback of type (int (*)(int)) and M3 passes (char (*)(char)). Both of then cast it to (void (*)(void)) while passing to M1 but M1 has no idea which version to cast it back to??? I think the registration API would at least need something like enum { (int (*)(int)), (char (*)(char))} reg_fn_callback_type; to be passed to it??? Moreover, isn't FAR* good enough with a right-type-enum? I mean is that a compiler dependent type? Or is it that my dream which ended with TurboC++ :) ? Hmm….I am still not sure how would M1 get to know the version of the callback to call. I mean suppose M2 passes a callback of type (int (*)(int)) and M3 passes (char (*)(char)). Both of then cast it to (void (*)(void)) while passing to M1 but M1 has no idea which version to cast it back to??? I think the registration API would at least need something like enum { (int (*)(int)), (char (*)(char))} reg_fn_callback_type; to be passed to it???

Moreover, isn’t FAR* good enough with a right-type-enum? I mean is that a compiler dependent type? Or is it that my dream which ended with TurboC++ :) ?

]]>