Re: [boost] Design conventions; passing functors

Subject: Re: [boost] Design conventions; passing functors
From: Joachim Faulhaber (afojgo_at_[hidden])
Date: 2009-03-04 16:31:26

2008/12/21 David Abrahams <dave_at_[hidden]>:
>
> 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?
>

Sorry for the late answer ... I obviously missed your post over Xmas :(

What I wanted to say was this:

Functors occur in my library (ITL) for the aggregation
of associated values on insertion in interval_maps
(aggregation on overlap):

And I thought about different ways to pass the
aggregating functor like:

template<class Domain, class Codomain, ...>
class interval_map{
 ...
 //(1) My current implementation is this:
 // Combinator is the aggregating functor template,
 // instantiated at compiletime
 template<template<class>class Combinator>
 interval_map& add(const value_type& value_pair)
 { /*Combinator template passed or instantiated somewhere*/  }
 ...
}

or

template<class Domain, class Codomain, ...>
class interval_map{
 //(3) Adaptable functor
 template<template<class>class Combinator>
 interval_map& add(const value_type& value_pair,
                   const Combinator<Codomain>& combine)
 { /*combine functor passed or called somewhere*/  }

All these variants have in common that the functor can
be chosen for the call of the function add.

interval_map<int,int> m;
m.add(interval_value_pair, combiner);

During the discussion I realized that the possibility of
passing the functor to every call of the add function is
*not* desirable. It provides too much flexibility that is
not needed and can lead to unnecessary errors.

To mix the aggregating functors for one interval_map m

m.add(interval_value_pair1, inplace_plus<int>());
m.add(interval_value_pair2, inplace_max<int>());

makes no sense.

So the combine functor should be constant for every
instantiation of an interval_map. (Or at least for every
object). Like the sort order is constant and can not
be changed for every call of insert.

typedef interval_map<int, int, partial_absorber, std::less, inplace_max>
   maximizer_interval_mapT;

In this case I do not have to pass the combine functor
with calls of the add member function.

maximizer_interval_mapT maximap;
...
maximap.add(make_pair(itv, x));
  // on overlap with itv compute maximum with x

see also maximize example:
http://herold-faulhaber.de/boost_itl/doc/libs/itl/doc/html/boost_itl/examples.html#boost_itl.examples.party

>> 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.
>
I thought about that but I do not like the idea to put more than the
compare order object into the container.

Sorry for the delay
Joachim