On Wed, Oct 12, 2011 at 8:03 AM, Maxim Yanchenko <maximyanchenko@yandex.ru>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