I agree that adding overloads for member function pointers can cause combinatorial explosion. However, support could be added for member function pointers by adding a get_callable function, that would return the function object itself if its a function object, or return a wrapped function object for member function pointers. Then get_callable is called before passing the function to the iterator or algorithm. Then you can use a metafunction for the adaptors. So you would write this: transformed_range<R, typename result_of_get_callable<F>::type> instead of: transformed_range<R, F>
________________________________ From: Neil Groves <neil@grovescomputing.com> To: boost@lists.boost.org Sent: Friday, March 16, 2012 9:43 AM Subject: Re: [boost] [range] adaptors and member functions pointers
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.
Neil Groves
On Fri, Mar 16, 2012 at 10:54 AM, Robert Jones <robertgbjones@gmail.com>wrote:
On Wed, Oct 12, 2011 at 4:03 PM, Maxim Yanchenko <maximyanchenko@yandex.ru>wrote:
Hi Jeff,
Of course this works, as well as STL iterator-based loops versus BOOST_FOREACH. 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'd like to see this patch make it into a release too, despite Jeff's misgivings. While I can appreciate Jeff's comments about consistency of Boost interfaces in different libraries, the Boost Range adaptors are absolutely all about brevity and clarity of exposition, and as such seem especially to benefit from this syntactic sugar.
Is this patch's appearance in a release 'in progress'? Anyone?
Thx,
- Rob.
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost