Subject: Re: [boost] [range] adaptors and member functions pointers
From: Jeffrey Lee Hellrung, Jr. (jeffrey.hellrung_at_[hidden])
Date: 2012-03-16 20:42:19
On Fri, Mar 16, 2012 at 1:33 PM, Giovanni Piero Deretta <gpderetta_at_[hidden]
> On Fri, Mar 16, 2012 at 6:56 PM, Jeffrey Lee Hellrung, Jr.
> <jeffrey.hellrung_at_[hidden]> wrote:
> > On Fri, Mar 16, 2012 at 6:43 AM, Neil Groves <neil_at_[hidden]
> >> Boosters,
> >> I am considering my position on this patch. I can see that it is
> >> syntactic sugar, but the reason I consciously omitted this was that it
> >> suffers from combinatorial explosion. I feel that one of the nice
> >> of the current Boost.Range design is that it reduces combinatorial
> >> explosion by breaking down items into their constituent orthogonal
> >> 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
> > don't see all of Boost moving to specially support
> > pointers-to-member-functions. Also, the workaround is seriously really
> > 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
> Personally, I think it would be a great feature.
>  http://stlab.adobe.com/group__concept__convertible__to__function.html
I don't have a strong opinion either way; I'm certainly sympathetic to the
syntactic convenience on the client side!
Referring to : incidentally, I too had been using a function in my
internal algorithms and data structures that allowed function objects,
pointers-to-members(-functions), and (yes, even) boost::reference_wrappers
of the aforementioned to all be treated uniformly, and I ultimately felt
that the uglification of the algorithms/data structures was worse than the
improvement at the use of the algorithm/data structure. Plus it took extra
documentation to justify the rationale for wrapping all my calls that would
otherwise look like "f(x)" with "invoke(f)(x)".
Boost list run by bdawes at acm.org, david.abrahams at rcn.com, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk