Hi, Michael Goffioul schrieb:
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?
Ooops, after re-reading it: yes I do, now. I was too focused on the post-condition ...
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().
I agree. Actually, I agreed -- halfheartedly ;-) -- already in my last mail (see citation above). But I am not sure about the reverse iterator fix anymore.
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().
There you're right as well. Another thing I overlooked ...
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()
100% agreement, now. Thanks for the clarification!
Ok, my understanding may be wrong, but this is how Microsoft implemented it... :)
It seems they stick better to the rules than the gcc people ... *surprise* Regards, Jens