A Simply Neat Example of Function Pointers in C

Example of function pointers in the linux kernel: http://lxr.linux.no/linux+v2.6.32/include/net/sock.h#L297

The cool thing about this is that, if you want to make your kernel socket 'event-driven', you can actually use this method to overwrite them and 'hijack' the callback. Then, when you're doing doing what you wanted to do, you can punt to the original callback (which you, hopefully, saved)

Example of this taking place: http://lxr.linux.no/linux+v2.6.32/drivers/scsi/iscsi_tcp.c#L...

Function pointers are a good means of allowing "flexible" finite state patterns, by making each function a state, directing all program flow to a "next" function pointer, and using conditionals within each state to begin transitions:

  /* an "active" state where a timer decrements unless the user hits a key. */
  if (timer<1) {prep_for_idle(); next = idle;}
  else if (user_hit_key) {timer+=100; next = active;}
  else {timer--; next = active;}

I use this pattern in haXe and Python, not C, but it applies equally well.

That's a pretty design, but a rather typical function pointer demonstration. It's at least more unusual if you change main to this:

    int main(void) {
        char *sayings[] = {
            "I know a secret!", "WHAT", "WHAT again", NULL
        };
        int i = 0;
    
        for (i = 0; sayings[i]; i++) {
            (i ? say_loud : say_soft)(sayings[i]);
        }
    	return 0;
    }

I modified the program so that the main function looks like:

  say = NULL;
  say("OH NOES");

When compiled with all warnings on, there are none. When run, it immediately segfaults. (The same would happen with any assignment from void*, like 'say = malloc(42)'. Nice.)

Edit: I knew this would get downmodded :) Why does any post implying that type safety is good get downmodded?

A common use of function pointers is in a dispatch table. For example, in a text editor, every ASCII character value, including control-characters and printable characters, is used as an index into an array of function pointers, each one of whom represents a function. For example the ^N character retrieves a function pointer for the moveToNextLine() function. The printable characters all are insertSelf() function.

Use of typedefs make the code more readable.

Instead of: int (* var_pointer_to_function)(int)

one must first do: typedef int (* funcptr)(int)

which is initially equally messy, but then allows one to declare function pointer variables in a simple succinct manner: funcptr foo

More importantly, function pointers can be used (especially in type definitions) as a way for polymorphism and object oriented code in C.

If you have a struct, and it has type definition pointers in it, you can create a set of initialization functions that set the function pointers to the correct "class functions" of that type.

I use function pointers in C everyday and it makes coding more robust and extremely easy to get the performance out of OOP code in a procedural environment when C++ isn't an option.

Another favorite is simple embedded languages where every statement or function has an entry in a table with a pointer to the function for execution.

That makes for a very simple parser.

Real world usage: an event-based architecture like the one employed in Keyspace [1]. We have an abstract class Callable, which has a member virtual void Execute() and a global convenience function Call(Callable) which just calls ->Execute(). So a Callable is something that can be called, ie. a function pointer. We then have two concrete implementations, one for global (C) function pointers and one for class member (C++) function pointers. The whole thing is in Callable.h and is <100 lines of code, hence very lightweight.

Then, in the framework layer, we register callbacks using Callables in the IOProcessor. So if you create a TCP server with a TCP listening socket, you have a TCPRead object and you set its onComplete member, which is a Callable, to &TCPServer::OnConnect and analogously for onClose. Then, once a connection is establised you post TCPRead or TCPWrite objects for the new socket to IOProcessor to receive read notifications or perform writes, again with members onComplete and onClose.

Then, in the application layer you have actual database code which uses the network abstractions in the framework layer (which abstract away I/O), but they also use Callables to have themselves get called back when, for example an entire message has been read (eg. command is then parsed and executed) from the TCP stream or a client connection is terminated (eg. commands are canceled).

The whole program is then one big infinite loop, each iteration IOProcessor::Poll() being waken up by the O/S because something has happened, and Callables being called in turn. (On BSD, we kqueue, on Linux epoll and on Win32 Completion Ports to receive readyness notifications.) We also have support timers, which are just a linked list of Callables, and when IOProcessor::Poll() blocks we pass in the amount of time until the next timer must be executed as the timeout.

Or you can use libev/libevent, but they're not lightweight and will force you to do things their way.

[1] AGPL source is at http://scalien.com

The same site has an interesting example of reference counting:

http://stoneship.org/journal/2007/c-reference-counting-and-y...

welcome to 1988

I'd like to congratulate you on your C function pointer hello world.

Not how he avoided using & or deref in the first snippet.