Alan Holloway <al***@kiaro.ne t> wrote:
I've just been reading the excellent Peter van der Linden excerpt [1]
from sun.com (i'm ordering the book when I get paid), and I am getting
to grips with the rules for understanding the complex declarations,
but, and this may sound like I am missing the bigger picture; when
would you use such a declaration like the following?
char * const *(*next)();
No idea when you would really need something exactly like that...
But since, according to that page, "next is a pointer to a function
returning a pointer to a read-only pointer-to-char" that could be
a function that lets you iterates over a list of (read-only) strings,
perhaps wrapping around back to the start of the list when you reach
the end, or giving you a randomly selected string each time you call
the function.
I think I am exposing a knowledge gap in regards to function pointers,
as i'm also not so clear when and why one would need to use one, but I
am hoping to hammer it in.. <OT> I understand that signal() needs a
function pointer to return to callback on receiving an arbitrary
signal,</OT> but i'm not sure of any other scenarios of when using a
function pointer would be warranted, and I guess that's the kind of
guidance i'm looking for.
Obviously, function pointers are always needed when you have callback
fucntions that you have to pass somehow to the function that installs
the callback. But probably the canonical example of a place where you
need a function pointer is the standard C function qsort(). Since it
is supposed to operate on arrays of arbitrary objects it needs to know
which function actually does the comparisons for the elements of the
array of objects you pass it.
But there are lots of other cases. Let's assume you're going to
write a calculator program that takes text input from the user
and you want to allow the use of a set of built-in functions.
Then a simple way to realize that would be to have an array
of structures like this
struct funcs {
char *func_name;
void ( * func_ptr ) ( void );
} func_arr[ ] = { { "func1", func1 },
{ "func2", func2 },
{ "func3", func3 } };
and when the user now types in some function name (stored in the char
array 'user_input') you can iterate over that array, trying to find
the function name and calling the associated function on success:
for ( i = 0; i < sizeof func_arr / sizeof *func_arr; i++ )
if ( ! strcmp( user_input, func_arr[ i ].func_name ) ) {
func_arr[ i ].func_ptr( );
break;
}
if ( i >= sizeof func_arr / sizeof *func_arr ) {
fprintf( stderr, "Sorry, no such function: %s\n", user_input );
exit( EXIT_FAILURE );
}
Other examples might include cases where you want to invoke different
sets of functions depending on the state of the program while avoiding
to check the current state over and over again before each function
call. In that case you could use have a set of function pointers that
get assigned the addresses of the appropriate functions whenever the
state of the program changes. For example, you might have a program
that is running all of the time but should behave differently during
the day and during the night. Then you could simply replace what the
pointers (by which you call the relevant functions) are pointing to
whenever you switch from day to night mode (or the other way round).
Finally, but here we're getting out of the realm of standard C, is
the use of functions that get loaded by some plug-in mechanism
while the program is already running. In that cases you typically
have function pointers in the main program that get assigned "useful"
values when you load that plug-in (e.g. a shared library), so that
you now can call them. You can't hardcode that functions into your
program because you don't know what these functions are going to be
until you load the plug-in (and the linker can't create a program
if it doesn't know about all the referenced functions in your program
but will quite happly accept it when you're working with function
pointers since these aren't functions but just well-defined variables,
even though they don't point to anything "useful" while you link).
Regards, Jens
--
\ Jens Thoms Toerring ___
Je***********@p hysik.fu-berlin.de
\______________ ____________
http://www.toerring.de 
