Re: [Boost-users] Overloading boost::for_each()

Subject: Re: [Boost-users] Overloading boost::for_each()
From: Jeremiah Willcock (jewillco_at_[hidden])
Date: 2010-08-29 16:34:05

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