Re: [boost] Design conventions; passing functors

Subject: Re: [boost] Design conventions; passing functors
From: Joachim Faulhaber (afojgo_at_[hidden])
Date: 2008-12-01 11:50:23

2008/11/29 David Abrahams <dave_at_[hidden]>:
>
>>
> 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