From: Steven Watanabe (watanabesj_at_[hidden])
Date: 2008-03-20 15:00:04
Sebastian Theophil wrote:
> If differences are represented as ints then
> INT_MAX - (-INT_MIN) < INT_MAX - 0
> If the difference is e.g. an int64 then as expected
> INT_MAX - (-INT_MIN) > INT_MAX - 0
> If anyone relies on either behavior, changing the difference type may be a problem.
Well, no one *should* rely on either behavior. It's undefined.
> My argument was precisely that on the architectures I'm aware of you can do the latter even when difference_type is short because shorts behave like a modulo space although they aren't required to do so. On the other hand I can iterate over all memory addresses I have although I couldn't allocate as much memory for myself. Representing the difference between two pointers would be just as important.
There are no guarantees about what pointer arithmetic does outside of a
contiguous block of memory.
> So your argument is ptrdiff_t shouldn't be int in the MSVC library implementation because that's a bad choice on a 32 bit system?
int is okay. If I try to create an array with a size larger than an int
the msvc 9.0 says error C2148: total size of array must not exceed
> I know my arguments rely on "observed behavior", i.e. on the fact that integers behave like a modulo space on Intel processors which MSVC is kind of limited to. The only other argument I can make is that counting_iterator should in my view be an iterator interface to the integral types with their well-known limitations.
If you want the behavior of integers, dereference the iterators and work
> I can iterate from SHORT_MIN to SHORT_MAX *and* I can compute the differences just as well as I can with shorts themselves.
Incidentally, short - short -> int
> If my implementation handles overflows fine, I don't have any problems. If it doesn't, why should counting_iterator try to be "betterer" than ptrdiff_t?
I don't think that it is better in practice.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk