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

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]
> wrote:

> 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]
> >wrote:
> >
> >> 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.
> >>
> >
> > 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[1] 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
>
> [1] 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 [1]: 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)".

- Jeff