tracer::~tracer() If we had been using objects where copying was expensive, we probably could not afford to use bind this way. There is an advantage to the copying, however. It means that the bind expression and its resulting binder are not dependent on the lifetime of the original object (t in this case), which is often the exact behavior desired. To avoid the copies, we must tell bind that we intend to pass it a reference that it is supposed to use rather than a value. We do this with boost::ref and boost::cref (for reference and reference to const, respectively), which are also part of the Boost.Bind library. Using boost::ref with our tracer class, the testing code now looks like this: tracer t; boost::bind(&tracer::print,boost::ref(t),_1)( std::string("I'm called directly on t\n")); Executing the code gives us this: tracer::tracer() I'm called directly on t tracer::~tracer That's exactly what's needed to avoid unnecessary copying. The bind expression uses the original instance, which means that there are no copies of the tracer object. Of course, it also means that the binder is now dependent upon the lifetime of the tracer instance. There's also another way of avoiding copies; just pass the argument by pointer rather than by value. tracer t; boost::bind(&tracer::print,&t,_1)( std::string("I'm called directly on t\n")); So, bind always copies. If you pass by value, the object is copied and that may be detrimental on performance or cause unwanted effects. To avoid copying the object, you can either use boost::ref/boost::cref or use pointer semantics. Virtual Functions Can Also Be Bound So far, we've seen how bind can work with non-member functions and non- virtual member functions, but it is, of course, also possible to bind a virtual member function. With Boost.Bind, you use virtual functions as you would non- virtual functionsthat is, just bind to the virtual function in the base class that first declared the member function virtual. That makes the binder useful with all derived types. If you bind against a more derived type, you restrict the classes with which the binder can be used. [5] Consider the following classes named base and derived: [5] This is no different than when declaring a pointer to a class in order to invoke a virtual member function. The more derived the type pointed to, the fewer classes can be bound to the pointer. class base { public: virtual void print() const { std::cout << "I am base.\n"; } virtual ~base() {} }; class derived : public base { public: void print() const { std::cout << "I am derived.\n"; } }; Using these classes, we can test the binding of a virtual function like so: derived d; base b; boost::bind(&base::print,_1)(b); boost::bind(&base::print,_1)(d); Running this code clearly shows that this works as one would hope and expect. I am base. I am derived. The fact that virtual functions are supported should come as no surprise to you, but now we've shown that it works just like other functions. On a related note, what would happen if you bind a member function that is later redefined by a derived class, or a virtual function that is public in the base class but private in the derived? Will things still work? If so, which behavior would you expect? Well, the behavior does not change whether you are using Boost.Bind or not. Thus, if you bind to a function that is redefined in another classthat is, it's not virtual and the derived class adds a member function with an identical signaturethe version in the base class is called. If a function is hidden, the binder can still be invoked, because it explicitly accesses the function in the base class, which works even for hidden member functions. Finally, if the virtual function is declared public in the base class, but is private in a derived class, invoking the function on an instance of the derived class succeeds, because the access is through a base instance, where the member is public. Of course, such a case indicates a seriously flawed design. Binding to Member Variables There are many occasions when you need to bind data members rather than member functions. For example, when using std::map or std::multimap, the element type is std::pair<key const,data>, but the information you want to use is often not the key, but the data. Suppose you want to pass the data from each element in a map to a function that takes a single argument of the data type. You need to create a binder that forwards the second member of each element (of type std::pair) to the bound function. Here's code that illustrates how to do that: void print_string(const std::string& s) { std::cout << s << '\n'; } std::map<int,std::string> my_map; my_map[0]="Boost"; my_map[1]="Bind"; std::for_each( my_map.begin(), my_map.end(), boost::bind(&print_string, boost::bind( &std::map<int,std::string>::value_type::second,_1))); You can bind to a member variable just as you can with a member function, or a free function. It should be noted that to make the code easier to read (and write), it's a good idea to use short and convenient names. In the previous example, the use of a typedef for the std::map helps improve readability. typedef std::map<int,std::string> map_type; boost::bind(&map_type::value_type::second,_1))); Although the need to bind to member variables does not arise as often as for member functions, it is still very convenient to be able to do so. Users of SGI STL (and derivatives thereof) are probably familiar with the select1st and select2nd functions. They are used to select the first or the second member of std::pair, which is the same thing that we're doing in this example. Note that bind works with arbitrary types and arbitrary names, which is definitively a plus. To Bind or Not to Bind The great flexibility brought by the Boost.Bind library also offers a challenge for the programmer, because it is sometimes very tempting to use a binder, although a separate function object is warranted. Many tasks can and should be accomplished with the help of Bind, but it's an error to go too farand the line is drawn where the code becomes hard to read, understand, and maintain. Unfortunately, the position of the line greatly depends on the programmers that share (by reading, maintaining, and extending) the code, as their experience must dictate what is acceptable and what is not. The advantage of using specialized function objects is that they can typically be made quite self-explanatory, and to provide the same clear message using binders is a challenge that we must diligently try to overcome. For example, if you need to create a nested bind that you have trouble understanding, chances are that you have gone too far. Let me explain this with code. #include <iostream> #include <string> #include <map> #include <vector> #include <algorithm> #include "boost/bind.hpp" void print(std::ostream* os,int i) { (*os) << i << '\n'; } int main() { std::map<std::string,std::vector<int> > m; m["Strange?"].push_back(1); m["Strange?"].push_back(2); m["Strange?"].push_back(3); m["Weird?"].push_back(4); m["Weird?"].push_back(5); std::for_each(m.begin(),m.end(), boost::bind(&print,&std::cout, boost::bind(&std::vector<int>::size, boost::bind( &std::map<std::string, std::vector<int> >::value_type::second,_1)))); } What does the preceding code actually do? There are people who read code like this fluently, [6] but for many of us mortals, it takes some time to figure out what's going on. Yes, the binder calls the member function size on whatever exists as the pair member second (the std::map<std::string,std::vector<int> >::value_type). In cases like this, where the problem is simple yet complex to express using a binder, it often makes sense to create a small function object instead of a complex binder that some people will definitely have a hard time understanding. A simple function object that does the same thing could look something like this: [6] Hello, Peter Dimov. class print_size { std::ostream& os_; typedef std::map<std::string,std::vector<int> > map_type; public: print_size(std::ostream& os):os_(os) {} void operator()( const map_type::value_type& x) const { os_ << x.second.size() << '\n'; } }; The great advantage in this case comes when we are using the function object, whose name is self-explanatory. std::for_each(m.begin(),m.end(),print_size(std::cout)); This (the source for the function object and the actual invocation) is to be compared with the version using a binder. std::for_each(m.begin(),m.end(), boost::bind(&print,&std::cout, boost::bind(&std::vector<int>::size, boost::bind( &std::map<std::string, std::vector<int> >::value_type::second,_1)))); . boost::ref and boost::cref (for reference and reference to const, respectively), which are also part of the Boost.Bind library. Using boost::ref with our tracer class, the testing code now looks