Ranges longer than size_t.max

[Era Scarecrow]

On Monday, 31 December 2012 at 17:47:36 UTC, Peter Alexander 
wrote:
> On Monday, 31 December 2012 at 17:43:34 UTC, Era Scarecrow 
> wrote:
>> On Saturday, 29 December 2012 at 01:18:37 UTC, Peter Alexander 
>> wrote:
>>> 1. Allow ranges to return BigInt for length.
>>> 2. Allow ranges like this but assert when .length overflows.
>>> 3. Allow ranges like this and just allow .length to overflow 
>>> dangerously.
>>> 4. Do not allow ranges like this.
>>
>> Option 5: Incorporate (emulation code?) for cent/ucent, then 
>> consider that the same as 1 but returning cent rather than 
>> BitInt.
>
> Two problems with this:
>
> 1. Still complicates range code (have to accomodate for both 
> size_t and ucent return value for .length).
>
> 2. ucent probably isn't enough either for these sorts of ranges.

  Perhaps, but having cent/ucent available would make a few people 
happy at least, although except for a few cases with databases 
and encryption it may not be that important right now.

  I remember trying to learn C/C++ and trying to do a very very 
simple code to get the number 1 doubled something like 100 times. 
After 31 it went to garbage (hey I was 14 at the time, god that 
was a long time ago). It took me a while to understand the 
problem.

  I ended up re-writing the whole thing in assembly that took 101 
bytes (COM file) and could double the number as many times as I 
wanted.