Basics Of Function Pointers In C

This is the kind of stuff I come to HN for. Thank you for helping me finally realize what .dll's really are.

If the name of a function is already the memory address of the function, what extra information does the pointer store? Couldn't you just assign the name of the function to, say, an int?

There's another interesting discussion here:

http://stackoverflow.com/questions/840501/how-do-function-po...

Elaborating on the OO bit, as derefr did an excellent job of talking about the usefulness of function pointers in a VM.

So, let's say I have a structure which I will use to represent objects in my game:

  typedef void (*thinkfunc_t)(void* self, unsigned int dt);

  typedef struct BaseFoo {
    float x,y,z;
    thinkfunc_t doThink;
  } BaseFoo;

  void null_think(void* self, unsigned int dt) { return 0; } /* empty think function */

  BaseFoo* Foo_new() {
    BaseFoo* ret;
    ret = calloc(1,sizeof(BaseFoo));
    ret->doThink = null_think;
    return ret;
  }

  BaseFoo* Foo_clone( BaseFoo* foo) {
    BaseFoo* ret;
    ret = Foo_new();
    memmove( ret, foo, sizeof(BaseFoo) );
    return ret;
  }

So, if I want to create a new BaseFoo, I just call Foo_new() and I'm off to the races; I get back a Foo object that, during my update loop, I can fiddle with:

  /* update loop snipped for brevity */
  BaseFoo* currentFoo;
  currentFoo = get_my_foo_from_my_big_foo_list();
  currentFoo->doThink(currentFoo, getFrameTimeInMilliseconds());

So, that's kind of cool, but what if I want to create a new, better foo, that actually moves? I do this:

  void move_think(void* self, unsigned int dt) {
    BaseFoo* foo = (BaseFoo*) self;
    foo->x += dt;
    foo->y += dt;
    foo->z += dt;
    return 0;
  }

  typedef BaseFoo MovingFoo;

  MovingFoo* MovingFoo_new() {
    MovingFoo* ret;
    ret = Foo_new();
    ret->doThink = move_think;
    return ret;
  }

So, this is very bland, but it gets across the idea that function pointers let me easily override member methods on class instances. You can imagine that, with a little cleverness, you can store arbitrary data into the struct, along with a table of function pointers to instance methods (a virtual function table).

This is a very fun, very deep rabbit hole.

In a lot of ways, you basically fake the type of prototypical inheritance you'd expect from, say, JavaScript.

EDIT:

Elaborating on another point--it's very common to use function pointers in a struct that then gets filled out by a dll or shared library.

For example, let's say that I've got a renderer that draws 3D stuff and conforms to an API. At runtime, I check what driver the user wants to use (software renderer, Direct3D, or OpenGL), and then I fill out the function pointers of that structure to point at the architecture and driver-specific methods I'd like to use.

The rest of my code doesn't change, because it only ever calls the interface exposed by the structure--the actual addresses pointed to by the function pointers are irrelevant.

(fitting user name, sir or madam!)

I'm guessing he's referring to declaring a global structure or collection of function pointers, and then using #ifdef's and compiler flags to actually assign those function pointers to things that make optimal sense for the architecture.

Or, at runtime (but hopefully before usage!) setting those global function pointers to point at routines optimal for the situation the program is running under--say, setting them to point at an optimized SSE3 vector routine if the CPU supports it.

Maybe that's it?