Re: [Boost-users] [Range] Strange!

Subject: Re: [Boost-users] [Range] Strange!
From: Eric Niebler (eniebler_at_[hidden])
Date: 2014-09-08 22:06:50

On 9/8/2014 7:53 AM, Albert Yiamakis wrote:
> 
> On 29/08/14 17:16, Eric Niebler wrote:
>> On 8/29/2014 1:21 AM, Neil Groves wrote:
>>> Clearly I can make the Boost.Range boost::distance O(1) by altering the
>>> implementation to not forward to the standard implementation. This would
>>> be required for almost all of the standard algorithms, hence I'd have to
>>> rewrite them all. 
>> Yes. IMO, Boost.Algorithm should have versions of ALL the standard
>> library algorithm, rewritten to work with the new-style iterator
>> categories. And yes, it's a lot of work, but not as much as you might
>> think. I should know, I'm just about finished my own complete
>> reimplementation of the algorithms for my range work.
> 
> Hello,
> 
> Although I 'm not familiar with the problem you discuss, reimplementing
> algorithms seems against avoiding duplication.
> I have a pull request on Boost.Algorithm arguing the opposite for any_of:
> 
> https://github.com/boostorg/algorithm/pull/3
> 
> The optimizations STL implementers may have come up with and the user's
> choice of an implementation are thrown out of the window. Am I missing
> something?

0) In my case, it's necessary research for my standardization proposal,
which represents a non-trivial rethink of how the algorithms work.

A) Nobody would be forced to use the new versions of the algorithms,
either mine or Boost.Algorithms's. I imagine folks would prefer the
std:: versions *when they meet their needs*.

i) The new algorithms would meet the needs of people using the new-style
iterator categories, and have forward-or-better traversal, but only only
readable access -- which maps to std::input_iterator_tag, and prevents
the sequence from being used with many std:: algorithms. These people
currently have no recourse.

a) My rewrite is to accommodate both ranges and sentinels, and obviates
the need to implement iterators with dummy sentinels and complicated
state and logic. std::istream_iterator and its ilk really should go away.

-- 
Eric Niebler
Boost.org
http://www.boost.org