2008/11/29 David Abrahams <dave@boostpro.com>:
A good choice that is both forward-looking and compatible with legacy code is to implement and document move semantics support (or a swappability requirement), and pass by value unless there's no need for an eventual copy.
looking at library code the 'eventually being copiedness' of functors seems to be a pragmatical criterion for many library authors on how to pass them (boost:: and even std::). If functors are eventually passed to a std algorithm inside the library code (or other copy intensive code), they are exposed as call by value in the libraries interface. If not they are often exposed as call by const reference parameters in the libraries interface.
As written earlier in this thread, I would prefer to pass functors const reference, and without additional wrappers (which is done by other boost libraries too). I do not call std::algorithms internally.
Please tell me, if there are strong arguments against that.
Extra copies of rvalues can be expensive, and function objects are often rvalues.
My own functor passing design head aces have disappeared by my decision *not* to expose the Combine (aggregate) functors in the interface of interval_map member functions at all. I am going to instantiate the Combine functor as template parameter for the interval_map class templates only. Similar to the Compare predicate in associative containers, the Combine functor of interval maps is then invariant for any given interval_map instance and can not change for a constructed interval_map object. This way, I think, the interval_map's interface is more easy to use correctly and harder to use incorrectly. Cheers Joachim