Re: [boost] [Bind] Interoperability of bind/mem_fn with transform_iterator

Subject: Re: [boost] [Bind] Interoperability of bind/mem_fn with transform_iterator
From: Samuel Debionne (debionne_at_[hidden])
Date: 2010-05-05 06:47:31

Le 05/05/2010 00:55, Jeffrey Lee Hellrung, Jr. a écrit :
> On 5/4/2010 3:49 PM, Daniel Walker wrote:
>> On Tue, May 4, 2010 at 1:49 PM, Peter Dimov<pdimov_at_[hidden]> wrote:
>>> Samuel Debionne:
>>>>
>>>> Anyway, in my opinion, using bind/mem_fn/lambda with transform_iterator
>>>> is a common use case. That would be great to have an option to add a
>>>> default constructor in those libs... or is it to risky ?
>>>
>>> The proper fix would be to make transform_iterator not require a
>>> default-constructible function object, by using boost::optional or an
>>> equivalent.
>>
>> That's a great idea! I took a look at it, and the required changes
>> seem to be minor. I made a ticket and attached a patch.
>> https://svn.boost.org/trac/boost/ticket/4189
>> I ran Boost.Iterator regression tests with gcc 4.2 and it passed
>> without error.
>>
>> Daniel Walker
>
> Maybe you should only conditionally wrap in a boost::optional, e.g., if
> has_trivial_constructor<F> is false (I don't think there's a standard
> is_default_constructible trait, right?).

I add a boost::optional use case in my "benchmark" and, performance 
wise, boost::optional is a much better option than boost::function to 
wrap non Default Constructible object function. I would say the game 
isn't worth the candle to wrap it conditionnaly, at least under vc10. I 
used the following wrapper :

template <class UnaryFunc>
struct optional_function
{
     optional_function() {}
     optional_function(UnaryFunc _func) : func_(_func) {}

     template <class Arg1>
     struct result {typedef typename 
boost::result_of<UnaryFunc(Arg1)>::type type;};

     template <class Arg1>
     typename result<Arg1>::type operator()(Arg1 _a1) const {return 
(*func_)(_a1);}

     boost::optional<UnaryFunc> func_;
};

template <class UnaryFunc>
optional_function<UnaryFunc>
make_optional_function(UnaryFunc _func) {return 
optional_function<UnaryFunc>(_func);}

Note that, to use a polymorphic object function like optional_function 
with transform_iterator, you need to apply the patch I suggested in 
https://svn.boost.org/trac/boost/ticket/1427

Finally, for my use case, the definitive solution is fast_mem_fn, an 
example of the function_type library. It's inlinable (and correctly 
inlined by vc10) and Default Constructible without the draw back of 
undefined runtime behaviour. I believe that this example could be a seed 
of a premium Boost library.

Samuel Debionne