First Mridula thank you for the nice post. I have a question though. You said about the advantages of using function objects over function pointers is that they are "1. More resilient to design changes as objects can be modified without affecting it's external interface."
Although I totally agree with the next remarks I am not quite sure about what you mean about this one. Thinking of functions it seems that you can also change the function's behavior without having to change its prototype.
If you meant that you can easily add new input params to function objects while you would need to change function's prototype it's not certain either as you would have to change the constructor's prototype in order to pass the new parameters to the internal state of the function object.
I know the post is quite old so I may not receive any answer but I hope there will be someone ending up reading this thread.
To answer Mike's questions.
All global functions shouldn't be systematically replaced with function objects. The article is only referring to the advantage of using function objects over function pointers. For a plain function there is no point creating an function object or call it through a pointer. Most of the time a "normal" call will be enough.
Function pointers and function objects really triggers in when you want to reuse the same code for different behaviors. The variation in behaviors will be implemented through "pointing" to a different function or passing a different function object. If you will always use the same behavior you should save you the pain of writing a new class or the loss in performance of indirecting a pointer to a function.
Also I would make one comment about the use of function objects over function pointers: this should not be a systematic rule. I definitely do agree with points 4 and 5 of Mridula's post but point 2 is not so obvious: inlining a function may not always mean better performance. It can actually result in a poorer performance and for this reason although you specify the function to be inline your compiler may simply ignore it if it thinks it will result in a worse performance.
So if you just don't need properties commented in points 3, 4 and 5 and you are not sure inlining a function will result in a better performance you may just use a function pointer.
In the case you just need to call a for_each algorithm on a simple function that will just perform some basics operations on the elements of the container you may not need to have to write a whole class just to provide it with a () operator.
At this point I will add one case when it is better to using function objects rather than function pointers. It's when you want to have a set of behaviors that are very similar to each other. In this case you may implement them through function objects that belong to the same hierarchy of classes and this way take advantage of inheritance and polymorphism.
My general point is you can't just say use this one rather that that one. It's sure function objects offer more power than function pointers but sometime it must be too much power than what you really need. There is no general rule. You have to use what better suits your needs.
About using function objects inheriting from unary and binary function classes, it's a good idea as many STL algorithms only apply to objects deriving from these classes. Although this should not need be always the case. The simplest reason not to do that is when you need functions with no params or more than two params.
Last: it's true that the language is unclear. A function object just means an object that behaves like a function. Strictly speaking it represents the instantiation of a class redefining operator(). But since the use you will make of function objects will always be through operator() and that this operator will not be static (otherwise it means you are not using the internal state of the class so it would question the use of a function object over a function pointer) then it means you will always have to instantiate a class into an object so although you are perfectly right saying it's not strictly correct we may just speak of object and class as if they were the same.