range processing extension(s)

From: James Mitchell (jimdesu_at_[hidden])
Date: 2001-12-22 04:23:48

Hello guys & gals,

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.

The impetus for this idea is that while I love iterator-based programming, I
can't stand having to carry two separate values to denote ranges.  I know
that you can use tie() or make_pair(), &c. to get around this, but it
muddles up otherwise clean code.

So what I was thinking was to code something akin to the following
code(which is probably faulty, but I'm more  trying to get the point across
than to proffer an implementation; I imagine you'd have to mess w/
iterator_traits and other such gak) :

template <typename B, typename E>
class range
{
  B begin_;
  E end_;
public:
  template< typename T>
  range(T container): begin_(container.begin()),
end_(container.end()){};
  range(B begin, E end):begin_(begin), end_(end){};
  /* canonical entries here */
  operator*() { return *begin_; }
  operator bool() { return begin_ == end_ };
  /* incrementers and decrementers here */
  B begin();
  E end();
};

This would allow me to use one value to denote the range with which I'm
working, allowing me to cleanly return it as the result of a function call.
I'd also write corresponding wrappers to the standard algorithms that would
call the regular algorithms, extracting begin() & end() from the range.  No
boundary-checking or other niceties, but it did occur to me that with the
right equality operator, that this might also be useful with generators.

So I've three questions:
1.  (the meta-question) Am I daft and there's a better way to do this sort
of thing that hasn't occurred to me?
2.  Are there any obvious gotchas that I should be aware of?
3.  Would there be sufficient interest in such a thing to submit it to
boost?

 Thanks for your time,

 James