|
Boost Users : |
Subject: Re: [Boost-users] [Range & c++0x Lambdas] Can this be done?
From: Nathan Crookston (nathan.crookston_at_[hidden])
Date: 2012-11-29 03:19:33
Jeff,
Jeffrey Lee Hellrung, Jr. wrote:
> Nathan Crookston wrote:
>>
>> 1. Both this and Michel's suggestions require C++11 features -- either
>> decltype or rvalue references. Extended transformed allows the creation of
>> a result_binder struct to be delayed until the reference type of the input
>> range is available. This would make it usable for non-lambda instances
>> where an explicit return type is desired without the fuss of defining a
>> separate functor (assuming the functor to be wrapped cannot be changed). I
>> believe a correct C++03 version of result_binder would need a large number
>> of operator() overloads depending on how many arguments it intends to
>> forward.
>>
>
> True, though this sounds like more of an implementation concern (don't get
> me wrong, it's a valid concern) than a capability concern.
>
Agreed. I think there's also slightly more mental drag involved with a
result_binder call, especially if I also need to remember where it resides
to #include it. But that's minor.
2. Such a syntax (transformed<R>(...)) has been used previously -- boost
>> bind's docs, referring to bind<R> syntax, state: "It is generally used
>> with function objects that do not, or cannot, expose result_type."[1]
>> Without begging for an Emerson quote, I believe consistency with bind in
>> this case will improve the usability enough to justify the required
>> changes. Note also that this is the only current adaptor[2] which takes a
>> function object with arbitrary return type (others must return something
>> which is convertible to bool). Note also that the changes are a pure
>> extension (previous usage continues unchanged).
>>
>
> I'm personally not swayed but it's a fair rationale nonetheless and
> ultimately your call since I'm not doing it :)
>
I've done all I plan to, unless a maintainer decides it's worth using and
would like some changes. Just to be clear, Nathan Ridge has been proposed
as a sub-maintainer, not myself. (FWIW, I think he's an excellent choice
for that position.)
Thanks,
Nate
Boost-users list run by williamkempf at hotmail.com, kalb at libertysoft.com, bjorn.karlsson at readsoft.com, gregod at cs.rpi.edu, wekempf at cox.net