Re: [boost] range processing extension(s)

From: brangdon_at_[hidden]
Date: 2001-12-22 12:39:13

In-Reply-To: <000901c18aca$5cbf91d0$a65ea240_at_[hidden]>
On Sat, 22 Dec 2001 01:23:48 -0800 James Mitchell (jimdesu_at_[hidden]) 
wrote:
> I am thinking of coding an extension to the standard library to make
> range-processing somewhat easier, and I was wondering if y'all wouldn't 
> mind providing some feedback.

This sort of thing has been raised before. See for example:
   http://groups.yahoo.com/group/boost/message/15353
   http://groups.yahoo.com/group/boost/message/20404
   
To put it another way, it's a good idea!

>   operator*() { return *begin_; }
>   operator bool() { return begin_ == end_ };
>   /* incrementers and decrementers here */

These things are potentially useful for implementing algorithms. I have 
previously tried to argue that would be a good thing, but without much 
success. If the implementations of algorithms don't use them, than life is 
simpler if they are not there.

The big question (in my view) is over the incrementors and decrementors. 
If we omit them, than a range becomes very like a container. We just use 
empty() instead of your operator bool(), and front() instead of your 
operator*(). I'd prefer this anyway - operator overloading is not really 
helpful here. Then we get algorithms acting directly on containers almost 
for free. This is powerfully attractive to many people.

Of course containers would normally be passed by reference, so we still 
need a range template for when by-reference isn't convenient (notably, for 
returning results). And we still have to decide whether this by-value 
range should offer incrementors and decrementors. And if it does, 
algorithms need to decide whether to use them.

For what it's worth, I still think incrementors and decrementors are 
beneficial. (I'd prefer names like pop_front() and pop_back() to operator 
overloading. We ought to support bi-directional ranges as well as forward 
ones.) Many algorithms can then be written in terms of ranges without 
using naked iterators, or begin/end, at all. This opens up the possibility 
of ranges which are not implemented as iterator pairs, but which, for 
example, use a NULL value or a counter to define their end. The algorithms 
which used this interface would become more general.

This is exciting to me, but the cost is that these range-algorithms 
wouldn't work with containers. I suspect there is a natural split in the 
concept tree, around whether sequences are by-value or by-reference. A 
problem arises because there is overlap in the middle. Some algorithms 
could be written equally well by-value or by-reference. Having a choice 
here makes an opportunity for incompatibility. I think this is what puts 
people off.

I am a partisan in this debate. I hope I have represented my opponent's 
views fairly.

-- Dave Harris