On Sun, 29 Aug 2010, Eric Niebler wrote:
On 8/29/2010 2:27 PM, Jeremiah Willcock wrote:
On Sun, 29 Aug 2010, Eric Niebler wrote:
On 8/29/2010 1:03 PM, Jeremiah Willcock wrote:
I think just overloading for_each() and writing algorithms in terms of that when possible would get the same benefits, though.
This way lies madness. The separation of containers and algorithms in the STL is what keeps it manageable. You don't want to implement N algorithms over M container types. You want to define a concept on which you can "overload" for_each.
Yes, that's what I meant. Have a default implementation, but specifically allow it to be overloaded, then make other algorithms use for_each() so that they can use overloaded versions. Maybe the base algorithm should be some kind of fold like it is in a functional language, though.
No. There is no one-algorithm-to-rule-them-all, with which all other algorithms can be implemented.
I agree, but there are some algorithms that can be written in terms of for_each or some more general construct.
There are different algorithms and different sequence types. The trick is matching the best algorithm implementation with the specific capabilities supported by the sequence. Hence the iterator categories. And segmented iterators are an extra category for which the algorithms can be specialized.
I agree. The extra capability I am talking about is that for_each() can be done for a particular sequence in a way that is faster than the standard implementation using iterators.
But I'm pretty sure you know all this, so I feel a bit strange saying it. Have I missed something?
I think the issue is that I was talking about overloading an existing algorithm, rather than having for_each() be a member of a concept like you suggested before. Basically, have a concept ForEachable that requires a for_each() operation, have it be refined by all iterator-based sequence concepts (or have a generic model defined), then let individual sequences model it explicitly/override the generic implementation when appropriate. Then, those algorithms that can be implemented using only for_each() -- but, as you said, not all algorithms -- can be changed to use the new concept and a for_each() operation rather than iterator-based loops. I think we agree on a lot more than it looks like; what I want is to give even more genericity/specialization potential to certain types of sequences with certain algorithms while still reusing a single algorithm implementation across all sequences. Some containers will still just want an iterator-based for_each(), and some algorithms will still need explicit iterators or ranges rather than just a for_each() operation; this new concept only changes the behavior of some sequences with some algorithms. -- Jeremiah Willcock