Question

I was just looking for a handy base class for a set of functors to be based on taking and int and returning void.

Thinking to use std/functional the functors are basically going to be unary_function<int,void> with operator().

Why is virtual result_type operator()(const argument_type& _Left) const = 0; not defined on the unary_function template? I’m guessing that it’s because there could be variations in constness…
Is there some other template I’ve missed that includes the operator()?

I haven’t done this in a while, am I missing something?

How would I also make use of existing functional like

std::ptr_fun< HWND, void >(someFunction);
std::pointer_to_unary_function<HWND, void>(someFunction);

EDIT:
Perhaps I should include the other half of the usage to make this complete. Maybe it’s the usage half that is not fitting in with the concept.

How would one pass the functor to a method and use it?

typedef unary_function<int,void> Functor;

void DoStuff(const Functor& functor) {
  int demo = 1;
  functor(demo);
}

functor as a unary_function doesn’t define operator() and so DoStuff doesn’t compile.

Answer 1

Template concepts are duck-typed. The fact that a class satisfying the UnaryFunction concept needs operator() is specified in the documentation and inferred from the templates which use template parameters satisfying that concept. There’s no need to spell out the function signature, or to require that it be virtual, that it take a const reference parameter, or that it be a const member function.

The unary_function template should not be thought of as an interface (and it isn’t designed as one). It’s certainly not a polymorphic base class. It’s a helper, which is used by classes that wish to implement the AdaptableUnaryFunction concept.

From the STL docs, which are reliable for the original design rationale: “the only reason it exists is to make defining Adaptable Unary Functions more convenient” – http://www.sgi.com/tech/stl/unary_function.html

The standard is similar: “The following classes are provided to simplify the typedefs of the argument and result types” (20.3.1/1)

Advanced usage – actually what’s required for UnaryFunction is that if f is a unary function object, and x is convertible to the argument type, then f(x) is a valid expression of the result type. It needn’t have a one-argument operator() at all, it’s fine to have a two-arg operator() with the second arg having a default value. Try defining that as a pure virtual function 😉

Second question, you make use of ptr_fun just by calling it with function name/pointer. Its template parameters will be inferred from the function type, so you don’t need to specify them. The result is an object of the corresponding pointer_to_unary_function template type.

To use the example straight from the STL docs:

transform(first, last, first,
    compose1(negate<double>, ptr_fun(fabs)));

This is approximately equivalent to:

for (auto current = first; current != last; ++current) {
    *current = -fabs(*current);
}

(where I use auto in its C++0x sense, meaning “I cannot be bothered / it is impossible to write the iterator type here”)

A function name/pointer can be used in transform (which takes a UnaryFunction template parameter), but not in compose1 (which takes an AdapatableUnaryFunction template parameter). So without ptr_fun, there’s no way to compose negate with fabs.

In response to your Edit, I stress, unary_function is not a polymorphic base class. You cannot usefully use it (or any of its instantiations) as a function parameter type.

If you want to use the UnaryFunction or AdaptableUnaryFunction concepts, then you must write a function template:

template <typename UnaryFunction>
void DoStuff(UnaryFunction &functor) {
    int demo = 1;
    functor(demo);
}

This only requires that the functor take a type which int converts to, though. It doesn’t require that it take exactly int and return exactly void. That’s usually an advantage.

If a template doesn’t do what you want, then unary_function is not for you. You haven’t missed anything: you can design your own interface with a virtual operator(), but the standard libraries don’t aim to provide any such thing.