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
> Jeffrey Lee Hellrung, Jr. <jeffrey.hellrung <at> gmail.com> writes:
> > > While transforming and filtering sequences, it's pretty common to call
> > > 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) |
> > >
> > It doesn't seem all that onerous to insert a boost::mem_fn  in there
> > (i.e., "transformed(boost::mem_fn(&Foo:::description))")...or does this
> > work?
> Hi Jeff,
> Of course this works, as well as STL iterator-based loops versus
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
> does this for quite a frequent case when you call element's member
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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk