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

Subject: Re: [boost] [Bind] Interoperability of bind/mem_fn with transform_iterator
From: Daniel Walker (daniel.j.walker_at_[hidden])
Date: 2010-05-05 17:08:42

On Tue, May 4, 2010 at 11:59 PM, Jeffrey Lee Hellrung, Jr.
<jhellrung_at_[hidden]> wrote:
> On 05/04/2010 06:20 PM, Daniel Walker wrote:
>>
>> On Tue, May 4, 2010 at 6:55 PM, Jeffrey Lee Hellrung, Jr.
>> <jhellrung_at_[hidden]>  wrote:
>>>
>>> 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
>>
>> What would that gain? It's a little hairy to implement on old
>> compilers. I'm not sure that it's worth it.
>
> The gain is you don't have to pay the cost of a boolean in space.  The
> boolean also has to be checked upon assignment and copy construction, so
> there is some amount of additional runtime overhead.

Thanks for the clarification. That seems like reasonable justification
for the change.

>
> What is "it" in "it's a little hairy to implement on old compilers"? The
> has_trivial_constructor metafunction, or a has_trivial_constructor-aware
> transform_iterator?  For the former, I'd believe it, but I would expect the
> Boost.TypeTraits version to be good enough.  For the latter, (and I could be
> very very wrong here, but) seems like the only thing you have to do is put
> an indirection layer when calling the function held by the
> transform_iterator, e.g., unwrap_optional(f)( ...args... ).  In fact, there
> may be such a function provided by Boost.Optional...

Boost.Optional doesn't have an unwrap that I could find. I uploaded a
new patch that conditionally uses optional based on
has_trivial_constructor per your suggestion. It has a simple unwrap
that should suffice. It passes regressions with gcc 4.2. My concern
with older compilers is that I know the authors of Boost.Iterator went
to some effort to support deficient compilers, but, unfortunately, I
am unable to test this patch on nearly as many. Still, this is a start
at least.

Daniel Walker