On 09/09/14 03:06, Eric Niebler wrote:
On 29/08/14 17:16, Eric Niebler 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
On 8/29/2014 1:21 AM, Neil Groves wrote: 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?
On 9/8/2014 7:53 AM, Albert Yiamakis wrote: 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