From: Thorsten Ottosen (nesotto_at_[hidden])
Date: 2003-11-03 07:02:59
"Pavol Droba" <droba_at_[hidden]> wrote in message
> On Mon, Nov 03, 2003 at 09:09:34PM +1100, Thorsten Ottosen wrote:
> > > Sure, we can use std::pair. iterator_range is not supposed to add much
> > > more. Only I find
> > > it a way more clean an easier to use, because, you need to specify
> > > one template argument
> > > (unlike in confusing pair) and the name denotes what is the semantic
> > > of the contained
> > > pair of iterators.
> > Please tell me what the invariant of iterator_range is suposed to be and
> > then justify why
> > reverse() don't break it. If it does, the operation does not make sense,
> > then there seem to be no
> > reason why this could not be a generic range.
> Well reverse was only added to simplyfy the handling for
but it will make the class dangerous to use. I'll try to explain.
The reason for encapsulating something in a class is to preserve
its invariant. If there is no invariant, everything can be made public and
some methods can be removed.
Every member function should preserve the invariant to ensure safe usage of
the class. That's why I want to know the invariant of
iterator_range. AFAICT, it is
1. begin() <= end()
2 empty() implies begin() == end()
this is a reasonable invariant (and suggest that the class is sound), but
this it not cool
iterartor_range< ... > r = find( ... );
sort( r.begin(), r.end() );
which suggest reverse() should not be part of the interface.
Besides, I couldn't find one place were you call it in the string library.
> I don't know about any reason why it should be a generic range. What
> whould it bring?
> > > Adding additional functionality and meaning to the iterator_range will
> > > break its original
> > > purpose.
> > >
> > so far we don't know what the purpose is.
> It's purpose is to encapsulate a pair of iterators delimiting a range in a
in which case reverse() does not make sense because it causes the iterator
not to delimit a range.
Anyway, just as you said iterator_range was a more generic version of my
basic_string attempt, then range is more general than iterator_range. You
made the string algorithms
as generic as possible, but you don't think the range should be as generic
as possible :-).