|
Boost : |
From: Victor A. Wagner, Jr. (vawjr_at_[hidden])
Date: 2002-10-14 10:57:45
At Monday 2002/10/14 08:24, you wrote:
>On 14 Oct 2002, David Abrahams wrote:
>
> > This is really about iterators, not iterator adaptors or
> > containers. Keep your eye on the bouncing iterator. Look at Table 75
> > (Bidirectional Iterator Requirements) in the standard. The first line
> > tells you everything you need to know:
> >
> > operational assertion/note
> > expression return type semantics pre/post-condition
> >
> > --r X& pre: there exists s such
> > that r == ++s.
> > post: s is dereferenceable.
>
>Shouldn't that say: r is dereferenceable?
>
>Anyway, all these assertions seem to require that, if a sequence is not
>empty, then --iterator_type(end()) return a valid iterator pointing before
>the end. So I can't use end-marker iterators. Good to know. Thanks.
Oh well, we didn't want to have "efficient" iterators for all our data
structures anyhow. (e.g. the "tree" which was proposed earlier...and my
offered "containerator" for it).
OTOH, maybe we can convince Jeremy that in his "new iterator categories" to
have an iterator that supports operator--() but NOT that for ALL iterators
--(++ni) == ni; specifically when ++ni == somecontainer.end().
Actually, I think the standard went a tad overboard here, unfortunately the
standard says what the standard says. <sarcasm>I'm sure there's some deep
reason like for the one which says the functor for accumulate() canNOT have
side effects, but the one for for_each() can</sarcasm>
> > --(++r) == r.
> > --r == --s implies r == s.
> > &r == &--r.
> >
>
>_______________________________________________
>Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Victor A. Wagner Jr. http://rudbek.com
PGP RSA fingerprint = 4D20 EBF6 0101 B069 3817 8DBF C846 E47A
PGP D-H fingerprint = 98BC 65E3 1A19 43EC 3908 65B9 F755 E6F4 63BB 9D93
The five most dangerous words in the English language:
"There oughta be a law"
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk