Boost logo

Boost :

Subject: Re: [boost] [range] adaptors and member functions pointers
From: Neil Groves (neil_at_[hidden])
Date: 2012-03-16 09:43:05


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_at_[hidden]>wrote:

> On Wed, Oct 12, 2011 at 4:03 PM, Maxim Yanchenko
> <maximyanchenko_at_[hidden]>wrote:
> >
> > Hi Jeff,
> >
> > Of course this works, as well as STL iterator-based loops versus
> > 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:

Boost list run by bdawes at, gregod at, cpdaniel at, john at