Best method for creating function "templates"

[Spiros Bousbouras]

I'm writing a library where on error the library functions are supposed
to call a function with prototype
unsigned long error_handler(unsigned long , unsigned long)
which should be supplied by the user. The question is what should the
library header contain to make it as easy as possible for the user to
declare or define such functions or pointers to such functions or casts
to pointers to such functions etc. and that if the prototype for an
error handler changes the user will have to do as few modifications as
possible to his source.

At present the header contains

typedef unsigned long (*error_handler_type)(unsigned long , unsigned long)
#define error_handler_def(foo_name , var1 , var2) \
unsigned long foo_name(unsigned long var_name1 , \
unsigned long var_name2)

so for a declaration the user can do

error_handler_type my_error_handler ;

and for a definition

error_handler_def(my_error_handler , foo_id , err_id) {
...code...
}

Is there a better way ?

 

[Spiros Bousbouras]

I'm writing a library where on error the library functions are supposed
to call a function with prototype
unsigned long error_handler(unsigned long , unsigned long)
which should be supplied by the user. The question is what should the
library header contain to make it as easy as possible for the user to
declare or define such functions or pointers to such functions or casts
to pointers to such functions etc. and that if the prototype for an
error handler changes the user will have to do as few modifications as
possible to his source.

At present the header contains

typedef unsigned long (*error_handler_type)(unsigned long , unsigned long)

Sorry , that should be
typedef unsigned long error_handler_type(unsigned long , unsigned long) ;

 

[luser- -droog]

What about parameter names? If the user has to supply a function to
process these values, it might help to know what they're for.

 

[Spiros Bousbouras]

What about parameter names? If the user has to supply a function to
process these values, it might help to know what they're for.

The documentation for the library will explain what the parameters are
for , there's no need to include the information in the header. But in
any case my actual source does have a comment which explains what the
parameters are for.

 

[Jorgen Grahn]

I'm writing a library where on error the library functions are supposed
to call a function with prototype
unsigned long error_handler(unsigned long , unsigned long)
which should be supplied by the user. The question is what should the
library header contain to make it as easy as possible for the user to
declare or define such functions or pointers to such functions or casts
to pointers to such functions etc. and that if the prototype for an
error handler changes the user will have to do as few modifications as
possible to his source. ....
Is there a better way ?

Not an answer, but it's a good idea to also provide a void* for
user-supplied data (unless one of those two unsigned longs serve that
purpose).

It can be really frustrating to get a callback, but not being able to
*do* anything useful because you don't have access to your own data
structures. That tends to end up with you making all your data
structures (reachable through) global variables -- ugh.

/Jorgen

 

[Spiros Bousbouras]

Not an answer, but it's a good idea to also provide a void* for
user-supplied data (unless one of those two unsigned longs serve that
purpose).

Yes. I posted a simplified version here but my actual code passes 4
parameters , the first 3 are unsigned long for module ID , function ID
and error ID respectively and the last void* for the reason you say.

 

[Dr Nick]

Not an answer, but it's a good idea to also provide a void* for
user-supplied data (unless one of those two unsigned longs serve that
purpose).

It can be really frustrating to get a callback, but not being able to
*do* anything useful because you don't have access to your own data
structures. That tends to end up with you making all your data
structures (reachable through) global variables -- ugh.

Yes yes yes. One of the most important lessons I've learnt in the last
few years. Sooner or later you end up going back and hacking the code
to put that user data pointer in, so you might as well put it there in
the first place. Another thing the standard library didn't necessarily
get completely right and which was too easy to slavishly copy.