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

Subject: Re: [Boost-users] [Range] Strange!
From: Albert Yiamakis (vkicefire_at_[hidden])
Date: 2014-09-09 08:12:58

On 09/09/14 03:06, Eric Niebler wrote:
> 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.
>

Thanks for the comprehensive reply.
Although it's true we 're not forced to use the Boost libraries, I would
hope it's possible to use - and already do so wherever I can -
Boost.Range as an elegant substitute to STL. Ideally, a _complete_
substitute until ranges are standardised, without worrying that certain
algorithms are inferior.

I 'm also curious as to why istream_iterator should go away. Surely it
is a fascinating aspect of the STL, being able to read straight from
input into an algorithm - ie integers into accumulate. I can imagine it
making an elegant range though, the one operating on cin called STDIN;
then we can write something like

accumulate(STDIN<int>, 0);

Albert