Boost logo

Boost Users :

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

Boost-users list run by williamkempf at, kalb at, bjorn.karlsson at, gregod at, wekempf at