Boost logo

Boost :

Subject: Re: [boost] [range] adaptors and member functions pointers
From: Jeffrey Lee Hellrung, Jr. (jeffrey.hellrung_at_[hidden])
Date: 2011-10-12 14:58:12


On Wed, Oct 12, 2011 at 8:03 AM, Maxim Yanchenko
<maximyanchenko_at_[hidden]>wrote:

> Jeffrey Lee Hellrung, Jr. <jeffrey.hellrung <at> gmail.com> writes:
>
> > > While transforming and filtering sequences, it's pretty common to call
> the
> > > elements' member functions, so I think it's worth adding some syntactic
> > > sugar for range adaptors in order to achieve cleaner syntax.
> > >
> > > foo_list | transformed(&Foo::description) |
> filtered(&std::string::size)
> > >
> >
> > It doesn't seem all that onerous to insert a boost::mem_fn [1] in there
> > (i.e., "transformed(boost::mem_fn(&Foo:::description))")...or does this
> not
> > work?
>
> Hi Jeff,
>
> Of course this works, as well as STL iterator-based loops versus
> BOOST_FOREACH.
>

I don't think that's a fair comparison at all.

> 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 won't argue with you, it *does* simplify the code. And when you want to
call a member function on the elements of a range, it *is* a pretty frequent
use case (although one could also use statically-bound rather than
dynamically-bound pointers-to-members). So these points I'm not disputing.

I just wonder where you draw the line in supporting pointers-to-members
directly. For example, should filtered also automatically wrap
pointers-to-members? What about other Boost libraries parametrized on
function objects? Thinking about it that way, I think, to avoid confusion
about which interfaces support pointers-to-members directly and which don't,
that, by default, none should (which seems to be pretty much the case now),
and force the user to wrap using boost::mem_fn (or similar). And like I
said earlier, is it all that onerous to insert a boost::mem_fn? Just
doesn't seem like that big of a wart to me.

- Jeff


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk