> Pavol Droba <firstname.lastname@example.org> writes:
> Question is there what should be the future of the iterator_range?
> Posibilities: - use it only internaly by string_algo library (and
> possibly rename it
> > to find_result)
> > -
move it outside as a separate utility - replace it with something
> > Current possibilities are half_open_range and
> > There are oher issues that has
been risen during this review. I will
> > address them later, when the
library will be ready for inclusion.
> I think it should be moved
outside and documented as a separate utility.
> It's valuable to be able
to pass containers around. It would be good if
> you'd look over the
functionality of half_open_range and see if there's
> anything worth
Matthew Wilson and me are working on a range
library, which I think will be quite useful.
It'll allow the concept of range: a pair of
iterators + it'll allow for easy manipulating of ranges in client
+ automatic conversion of containers to
We'll post a version 0.01 in a few