Re: [boost] [range] adaptors and member functions pointers

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>

instead of:

transformed_range<R, F>

>________________________________
> From: Neil Groves <neil_at_[hidden]>
>To: boost_at_[hidden] 
>Sent: Friday, March 16, 2012 9:43 AM
>Subject: Re: [boost] [range] adaptors and member functions pointers
> 
>Boosters,
>
>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.
>
>Neil Groves
>
>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
>> <maximyanchenko_at_[hidden]>wrote:
>>
>> >
>> > 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,
>> and
>> > 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?
>>
>> Thx,
>>
>> - Rob.
>>
>> _______________________________________________
>> Unsubscribe & other changes:
>> http://lists.boost.org/mailman/listinfo.cgi/boost
>>
>
>_______________________________________________
>Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
>
>
>