On 9/8/2014 7:53 AM, Albert Yiamakis 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?
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