Re: [boost] Proposed patch for boost::counting_iterator

From: Steven Watanabe (watanabesj_at_[hidden])
Date: 2008-03-20 15:00:04

AMDG

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 
can hold
the msvc 9.0 says error C2148: total size of array must not exceed 
0x7fffffff bytes

> 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 
with integers.

>  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.

In Christ,
Steven Watanabe