Re: [boost] Design conventions; passing functors

Subject: Re: [boost] Design conventions; passing functors
From: Joachim Faulhaber (afojgo_at_[hidden])
Date: 2008-11-06 12:28:14

2008/11/6 Steven Watanabe <watanabesj_at_[hidden]>:
>> <snip>
>>
>> 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*/  }
>>
>
> Can't you use:
>
> template<class Combinator>
> interval_map& add(const value_type& value_pair, const Combinator& combine);
> ?
I could
>
> In other words, does Combinator really have to be a template?
>
No it doesn't. But any Combinator has to combine Codomain values.
I feel that this is expressed more precisely in definition (3).

>> Now, there seems to be a convention from the STL that functors
>> shall be passed BY VALUE.
>>
>> <snip>
>>
>> I do not really understand this convention and feel some
>> resistance to follow it. In addition the call by value
>> implementation can (and will) lead to heavy inefficiency
>> by unaware usage of fat functors.
>
> The assumption is that function objects are not fat.
> If you have a large function object, it is always
> possible to create another function object that just
> stores a reference to the original function object.
>
Unfortunately the assumption can not be that all programmers
are always aware of the many c++ intricacies.

There's a rule stated by Scott Meyers in one of his books:
"Make your classes easy to use correctly and difficult to
use incorrectly."

In common, I would expect, that class objects
are passed by reference. So in the struggle to meet the
next deadline one could unknowingly code

m.add(some, add_if_in(big_set));

where add_if_in contains the a big set which then is copied
and again copied with every subsequent functor passing inside add.

The perfect programmer won't do that, but this library code is
IMO easy to use incorrectly.

Joachim