[GiNaC-list] Use of STL iterators in GiNaC

[Michael Goffioul]

On Thu, Apr 16, 2009 at 2:04 PM, Jens Vollinga <jensv at nikhef.nl> wrote:
>> I'm no C++ standard expert, but when I look at
>> http://www.sgi.com/tech/stl/RandomAccessIterator.html
>> my understanding of the precondition for "i += n" is that you cannot
>> go after end().
>
> It seems that the standard (I only have the draft. Hopefully there is no
> difference to the final version in the areas under consideration) and the
> SGI documentation deviate from each other. In SGI there are pre- and
> postconditions on +, -, +=, and -=. And these conditions are violated in the
> examples as you point out. But in the standard +, -, +=, -= have NO
> pre-/postconditions to them! See 24.1.5. The confusing part is, that -- and
> ++ DO have such conditions. But for the ++ operation, it is explicitly
> allowed to go past-the-end. See 24.1.4. So no problem for the code in
> factor.cpp. The code in utils.h seems to be against the standard, though,
> but I am no language lawyer and so I am maybe misinterpreting the conditions
> there. In case, this can be fixed by using reverse iterators.

OK, I had a look in a draft C++ standard document I could find on the
web, and when reading 24.1.3, the "pre" condition for ++r is that r must
be dereferenceable. When r == end(), it is not dereferenceable, so you
cannot do ++r. Don't you have the same interpretation?

In 24.1.4, the pre condition for --r is that there exists s such that r == ++s.
For ++s to be valid, s must be dereferenceable, so s cannot be before begin().
Moreover, the post condition is that r is dereferenceable (there seems to be
a typo in the version I have, which says s is dereferenceable, but this doesn't
make sense), so r cannot be before begin().

In 24.1.5, there's no pre condition on "r += n", but I think it can be deduced
from the operational semantics and the interpretation above that you cannot
go past end().

My general understanding is:
1) you cannot go before begin()
2) you can go after the last element, but only by an offset of 1, which
corresponds to end()

Ok, my understanding may be wrong, but this is how Microsoft
implemented it... :)

Michael.