Re: [boost] Design conventions; passing functors

Subject: Re: [boost] Design conventions; passing functors
From: David Abrahams (dave_at_[hidden])
Date: 2008-12-20 19:03:27

on Mon Dec 01 2008, "Joachim Faulhaber" <afojgo-AT-googlemail.com> wrote:

> 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.

Interesting.  I'm not sure I see the point, but interesting.

>>
>>> 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'm sorry, I have no idea what I just read (and re-read) there. Could
you rephrase?

> 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.

I'm not sure what you're saying.  Are you planning to store an instance
of the function object in the container?  That is the normal behavior of
standard containers.

-- 
Dave Abrahams
BoostPro Computing
http://www.boostpro.com