Subject: Re: [boost] [range] adaptors and member functions pointers
From: paul Fultz (pfultz2_at_[hidden])
Date: 2012-03-16 10:41:28
I agree that adding overloads for member function pointers can cause
combinatorial explosion. However, support could be added for member
function pointers by adding a get_callable function, that would return the
function object itself if its a function object, or return a wrapped function
object for member function pointers. Then get_callable is called before
passing the function to the iterator or algorithm. Then you can use a
metafunction for the adaptors. So you would write this:
transformed_range<R, typename result_of_get_callable<F>::type>
> From: Neil Groves <neil_at_[hidden]>
>Sent: Friday, March 16, 2012 9:43 AM
>Subject: Re: [boost] [range] adaptors and member functions pointers
>I am considering my position on this patch. I can see that it is pleasant
>syntactic sugar, but the reason I consciously omitted this was that it
>suffers from combinatorial explosion. I feel that one of the nice aspects
>of the current Boost.Range design is that it reduces combinatorial
>explosion by breaking down items into their constituent orthogonal parts.
>However I am reconsidering since there are a growing number of people
>requesting this feature, and perhaps the pragmatic convenience outweighs
>the slightly theoretical design concern. I need to make some effort to
>tackle some of the Boost.Range suggestions that have been accumulating
>during a period of ill health. I apologize for slow responses. It is
>important, to me, to make interface changes that I do not later regret.
>This needs some further investigation and thought.
>On Fri, Mar 16, 2012 at 10:54 AM, Robert Jones <robertgbjones_at_[hidden]>wrote:
>> On Wed, Oct 12, 2011 at 4:03 PM, Maxim Yanchenko
>> > Hi Jeff,
>> > Of course this works, as well as STL iterator-based loops versus
>> > BOOST_FOREACH.
>> > As I said, this is just a syntactic sugar that makes the code cleaner,
>> > it
>> > does this for quite a frequent case when you call element's member
>> > function.
>> I'd like to see this patch make it into a release too, despite Jeff's
>> misgivings. While I can
>> appreciate Jeff's comments about consistency of Boost interfaces in
>> different libraries, the
>> Boost Range adaptors are absolutely all about brevity and clarity of
>> exposition, and as
>> such seem especially to benefit from this syntactic sugar.
>> Is this patch's appearance in a release 'in progress'? Anyone?
>> - Rob.
>> Unsubscribe & other changes:
>Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk