Date: 2001-11-04 16:29:11
On Mon, 29 Oct 2001 Kevin S. Van Horn wrote:
> Although I like the idea of having the *option* of passing the range as
> a single object, making that the only option causes you to lose
> some power and flexibility.
I wouldn't suggest that. Some algorithms, such as binary search, seem to
fit iterator pairs quite well. However, there are many algorithms where a
single range object makes sense and I think it should be preferred for
The whole area needs some experiment and practical experience. I don't
know if boost is the right place for this.
> I prefer the Unix philosophy of flexible combinations of simple
> tools, and "do one thing and do it well". Conveniences like
> the single-object range should be built on top of more flexible
> and simple primitives.
I'm not convinced that iterator pairs are more flexible. Although they can
be made to fit sequences terminated by an EOF value, it is a bit of a
stretch. Explicit ranges cope with that easily.
The way I look at it, much of the STL is based around the concept of a
sequence, and it is good design to represent fundamental concepts
explicitly. A pair of iterators is not a very explicit representation; it
is at the wrong level of abstraction. Stroustrup says more about the
problems this causes in C++PL, $18.3.1.
> I strongly object to the "src.empty()" syntax, as it is too restrictive
> -- it forces InputRange to be a class type that already has a
> member function "empty" defined.
I'm aware of this point of view but I see it as orthogonal to the issues
of input sequences. I will go with whatever the prevailing opinion is. I
use that syntax only because it is what the rest of the STL uses, and I
don't want to get distracted by what I consider a side-issue.
> For example, I couldn't use a pair of iterators as my range.
I don't see how using empty(s) instead of s.empty() will help there.
Unless you are thinking of empty(b,e) - but that is back to passing 2
-- Dave Harris
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk