Introduction to Function Objects

Suppose you have a list of words and you want to count how many of them come before the word "m" in alphabetical order. A general counting algorithm can walk through every element of the list, but it does not know your rule. For each element it needs to ask a question, and the question you need is not "is this element equal to some value?" It is "is this element less than a particular string?"

The central idea of this article is that the comparison belongs to a small object you pass in, rather than being written into the algorithm itself. A function object can supply that question to a general algorithm, and seeing how it does so is the goal of the next several sections.

A function object is an object that can be used as if it were a function. The notation Less_than<string>{s} describes an object that compares to the string called s. The important detail is that the object holds that string inside itself. When you create it, the value it compares against travels with it. Calling the object with an element asks whether that element is less than the stored string.

The following example is an original illustration built from this idea. It defines a class template that carries a value and compares against it, then passes an object of that class to the standard count_if algorithm. Read the code once before looking at the output, and notice that the algorithm itself never mentions the letter m.

Without function objects, a separate ordinary function would be needed for each value you might want to compare against. Each value type might need its own function as well. The alternative would be to keep the value in a global variable that the function reads. Both approaches make the code harder to follow, because the knowledge needed to understand one comparison is spread across several places.

Function objects avoid both problems. You do not write a separate function for each value and type, and you do not introduce global variables to hold the values. The comparison and the value it uses are packaged together in one unit, which you create wherever you need it.

Carrying data is only half of the story. For a simple function object such as Less_than, inlining is straightforward. Inlining means the body of the operation can be placed directly where it is used, instead of being reached through a separate function call at run time. Because of this, a call to Less_than is far more efficient than an indirect function call.

The two properties support each other. Carrying data makes the object convenient, and its efficiency makes it practical. Together they explain why function objects are especially useful as arguments to algorithms, which may call the argument many times over a sequence of elements. In the count_if example, the comparison runs once for every element in the list, so a cheap call matters.

The word policy describes the role of the object. The algorithm is general: it knows how to walk a sequence and count matches. The policy object decides what counts as a match. In this sense a policy object is a function object that defines the meaning of a key operation inside a general algorithm such as count().

Changing the policy changes the meaning of the operation without changing the algorithm. The count_if call in the earlier example could be given a different policy for a different question, such as an object that tests for words longer than a given length, and the algorithm would be reused unchanged.

The example above has a drawback. You have to define Less_than separately from its use, and that separation feels inconvenient when the object is needed for only one call. To address this, the language provides a notation for implicitly generating function objects. Its motivation is to let you describe the object at the point where it is needed instead of writing a separate definition first.

Sometimes a function needs several pieces of information to do its work, but the code that wants to use it only has some of those pieces when it is ready to call. One option is to rewrite the function. Another is to wrap it: keep the original function as it is, and produce a new callable that already holds some of the information and asks only for the rest. Function adaptors are the tools built around that second idea.

Notice the direction of the relationship. An ordinary function takes data in and gives a result back. An adaptor takes a function in and gives a different callable object back. The adaptor does not perform the work the original function was written to do. Its job is to package the original function into a new form that a caller can use more conveniently. The adaptor reshapes how the function is called without changing what the function does.

The technique that gives adaptors their practical value is called argument binding. The same idea goes by two other names: Currying and partial evaluation. All three names point to one act: fixing some of a function's arguments ahead of time, so that the resulting object needs fewer arguments when it is finally called.

The word partial is the useful clue. The function is not evaluated in full at the point of binding. Only part of its input is supplied. The remaining input is left open, and the returned object waits for it. When the missing inputs arrive and the object is invoked, the original function receives the complete set it expects.

The standard library provides two adaptors for argument binding: bind() and mem_fn(). Each takes a function-like thing and returns an object that can be used to invoke it. When you meet them in code, recognize them as adaptors that perform the partial evaluation described above.

Binders were heavily used in the past, but most of those uses are now more easily expressed with lambdas. A lambda is an alternative to an adaptor for argument binding. In the cases the material describes, the same effect can be written more directly as a lambda, so an adaptor is no longer the first tool most programmers reach for.

Check your answer against the worked example earlier in the article. The structure is the same: one argument is fixed in advance, the returned object needs fewer arguments, and invoking it sends the complete set to the original function. The answer is 12.