Subject: Re: [boost] [range] adaptors and member functions pointers
From: Giovanni Piero Deretta (gpderetta_at_[hidden])
Date: 2012-03-16 16:33:00
On Fri, Mar 16, 2012 at 6:56 PM, Jeffrey Lee Hellrung, Jr.
> On Fri, Mar 16, 2012 at 6:43 AM, Neil Groves <neil_at_[hidden]>wrote:
>> 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.
> My unrequested opinion: First, I understand the motivation. However, I
> think it would be inconsistent and confusing if some libraries in Boost
> treated pointers-to-member-functions specially while others did not. And I
> don't see all of Boost moving to specially support
> pointers-to-member-functions. Also, the workaround is seriously really not
> so bad (explicitly wrapping with mem_fn), especially given C++'s general
> penchant for verbosity.
Note that there is precedent in C++ for treating ptr-to-members and
ptr-to-member functions specially, see for example the
ConvertibleToFunction concept employed by Adobe ASL library.
Also, boost::bind (and std::bind) do treat them specially, not requiring mem_fn.
Personally, I think it would be a great feature.
-- gpd  http://stlab.adobe.com/group__concept__convertible__to__function.html
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk