Monday, September 25, 2006

Function Pointers in C/C++ and boost::bind

In a previous blog entry, I showed the Windows QueueUserAPC function, and how you could use it to get other threads to execute functions. Now this was kind of cool, but if the only functions we can use are free functions which have only a single 32 bit parameter, not so useful. I said I'd explain how to use boost::bind to solve this.

Now, I'm not going to explain how this interacts with QueueUserAPC just yet, because explaining boost functions and bind is well big enough for a blog entry of it's own. Here it is.

Intro - Function Pointers in C and C++

If you're not familiar with what a function pointer even is, well:

  • All your code that you write gets turned into a big bunch of binary stuff by your compiler.
  • In order for this code to run, it has to load this binary stuff into memory
  • Once the binary stuff is in memory, the CPU can be told to execute arbitrary bits of it. This is what C/C++ does behind the scenes when you normally call a function
  • A function pointer in C/C++ is a pointer to a bit of that memory where a function lives.
  • When more code is loaded, or passed around from one part to another, you can get pointers to this new code as well as the static stuff which you wrote upfront.
  • This lets you do things like call functions which didn't exist when you compiled the program, (ie: DLL's), or tell some code to execute a runtime-specified piece of other code on some event (ie: callback functions)

If you're not familiar with function pointers in C, here's an example:

void Print( int a ) {
    std::cout << "Free Function, a = " << a << std::endl; 

void main() {
     void( *x )(int) = &a_function;
      // we now have an object x, which is a pointer to function of type void(*)(int).
     // it happens to be pointing at our Print function
     x( 5 ); //call it 

This syntax is fine and dandy for C functions, which don't have classes or anything, so the types are all pretty simple, however in C++, we have classes, which have member functions (or methods if you prefer to call them that). Imagine the following class:

class FooClass {
    void Print( int a ) {
         std::cout << "A FooClass, param = "<< a <<" this = " << this << std::endl;

Now, if we want to get a pointer to the Print function, we have to write some extra stuff so the compiler can tell that it's a member function of FooClass, and we also have to pass the instance, so the compiler knows which FooClass the Print function should belong to. We might have 50 of FooClass in an array and it's got to be able to figure out which one is the right one.

FooClass* myFoo = new FooClass(); //create an instance of our FooClass
void( FooClass::* x )(int) = &FooClass::Print 
// we now have an object called x, which is a pointer to function of type void(FooClass::*)(int)
// it happens to be pointing at our FooClass::Print function, but it doesn't know which FooClass instance yet

(myFoo->*x)( 5 );
//call the function, telling it that the FooClass represented by myFoo is the one to use 
//, as if we'd called myFoo->Print( 5 );

As you may well have noticed, using pointers to class members sucks. I've done a fair bit of this kind of thing and I had to go and look up the documentation to remember quite how it was supposed to work. C++ cops a lot of flak for this kind of stuff, and deservedly so in my humble opinion.

We could always make it nicer by using some typedef's, but it's still ugly, still probably wouldn't make sense to most novice programmers, and we still have the problem that the function pointer doesn't stand alone - we also need to pass the object instance around.

If they didn't know any better, but wanted to use this kind of thing, most programmers would probably end up creating some kind of struct which contained the instance, the function pointer, and some other arbitrary data, and passing that around the place. That at least makes it possible, but it still sucks.


If you take the following 3 things:

  • Function pointer type declarations suck
  • You can do lots of amazing stuff with templates in C++
  • The guys who write the boost libraries are really really smart

Then, for free functions, we get this:
void Print( int a ) {
    std::cout << "A Free function, param = "<< a << std::endl;

void main() {
    void( *oldFunc )(int) = &Print; //C style function pointer
    oldFunc( 5 );

    boost::function<void(int)> newFunc = &Print; //boost function
    newFunc( 5 ); 

It's just my opinion of course, but I think the C style function pointer with the variable name in between the void and the (int) is confusing, whereas the boost function just behaves how you'd expect it to. Code that clearly states what it does, and then simply does it, is the best code.

Even though this is a trivial example and the boost one isn't actually much nicer, I'd still use it just because it's easier to read. However, it still hasn't solved the problem of passing around the instance along with the function for C++ members...


What boost::bind does, is "bind" parameters into a boost::function object (how this actually happens is a bit beyond the scope of this article so I won't go into it )... like an object instance (or a pointer to one). Observe and rejoice

class FooClass {
     void Print( int a ) {
         std::cout << "A FooClass, param = "<< a <<" this = " << this << std::endl;

void main() {
    FooClass *myFoo = new FooClass();
    void( FooClass::* oldFunc )(int) = &FooClass::Print; //C style function pointer
    (myFoo->*oldFunc)( 5 );

    boost::function<void(int)> newFunc = boost::bind( &FooClass::Print, myFoo, _1 ); //boost function      
    newFunc( 5 );

What is effectively happening, is that myFoo is being "bound" into the newFunc object. Think of it as creating a private variable inside newFunc and sticking myFoo in it. When newFunc is invoked, it will use myFoo as a parameter.

Boost is smart enough to figure out that we're passing in an instance of FooClass instead of just a number or string or whatever, and so when the function is called, it will use that instance, and will do myFoo->Print() automagically for you. This means we don't have to carry the instance round or worry about the awful syntax when we want to use it, we just bind it into the function object, and away we go.

But but but, what's the _1?

Aha! Remember, boost::bind is not "mysterious way to get functions to work", it's "bind a parameter into a function object." It can bind any variable of any type, so long as it matches the boost::function which will hold it. Also, it wants to bind variables for every parameter in the function. This is also perfectly valid code:

boost::function<void()> newFunc = boost::bind( &FooClass::Print, instance, 6 );
newFunc(); //this will call Print with 6 as the 'a' parameter.

What the heck, I hear you say? We're calling the Print function, which takes one int as a parameter, but we're not passing any int's to it. This is just boost::bind doing it's thing. Remember, it wants to bind every parameter it can.

...But if you bind every parameter, you can't supply them later!

This is what the _1 is for. It means "The first parameter, which will be supplied later". In our first example, we used _1 to indicate that we wouldn't bind the parameter to newFunc in straight away, and that we would supply it later on when we invoke the function.

The cool thing about this is, you can mix and match them, and do all kinds of silly stuff, like this:

int MessageBox( HWND, char*, char*, int ); 
//Probably looks familiar to windows coders

boost::function<int( int, char*, char*, HWND )> reversed_params =
      boost::bind( &MessageBox, _4, _3, _2, _1 ); 
      //use the _ markers to move the parameters around

boost::function<int( char*, char* )> bind_some =
      boost::bind( &MessageBox, m_hWnd, _1, _2, 0 ); 
      // bind in some parameters, but leave others to be supplied later,
      // creating a function where the user must supply 2 params instead of 4 

If you're a functional programming fanatic, you'll have been whinging about closures for years, and how langauges that don't have them suck. boost::bind isn't a closure, but if you know what you're doing you can get pretty close to acheiving the same functionality as one, which is pretty cool for C++

Anyway. I've spent ages writing this so hopefully someone will read it. Good Luck!


Paul R. Potts said...

Hi there,

Interesting piece. You and/or your readers might be interested in an entry I wrote on pointers to members in C++ and their relation to generic functions in CLOS/Dylan. I also argue that while the syntax for pointers to members is obscure and awkward, it does make at least some logical sense when you compare it to the way other C++ declarations are built up.

Also see the comments on the above posting for a note on the STL mem_fun.



Koshkat said...


this is probably the best article I' ve found on the web explaining boost::bind in a very simple and practical way, that really helped me understanding !

Congrats !


Zach said...

Great article. Thanks for the detailed description on boost::bind. When do you think you will get a chance to talk about using bind and function with the Win32 API.


padawan said...

Google brought me to this post and I must say... thank you very much! The way you explained it's easy to understand.


Miroslav Beranič ml. said...

I will join to the others. Nice work. Solved my problem with boost/bind+function problem. Thanks a lot.

roonda said...

Huge thanks for explaining this stuff. The boost documentation doesn't do it anywhere near so well. Good work.

Pac said...

Could you please format the code a little bit? It seems to be all in one-line. Thanks!

selcuk koyuncu said...

definitly pretty good

Mateusz said...
This comment has been removed by the author.
parados said...

hi !!

this exactly what i search and i found it

you save my life !!!!

my problem is that i create a class named gui_event and it's use to organize event like key-down and key-up mousemove ..etc

and i have another class to create object like button and window

i try to get event from gui_event class and pass it to the class i try pointer to member but.....

one word amazing

shashank said...

Thanks a lot for spending time on this!! So far, this was the best precise and concise introduction to boos:bind!! Really appreciate the effort!

Colby said...

You should write documentation for all of the Boost libraries, and get paid to do it! The "official" doc on the Boost website is terrible. *sigh*

Anthony Mihirana de Silva said...

Excellent! Thorough, concise and clear!
Thanks :-)

Ashish Ranjan said...

I appreciate the way you have written the article. I was always wondering why boost::Bind is required when we have functional pointer. But you have clearly explained the need and pro of boost::Bind.