Subject: Re: [boost] [Bind] Interoperability of bind/mem_fn with transform_iterator
From: Jeffrey Lee Hellrung, Jr. (jhellrung_at_[hidden])
Date: 2010-05-04 23:59:53
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
>>> 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.
>>> I ran Boost.Iterator regression tests with gcc 4.2 and it passed without
>>> 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.
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...