Ranges longer than size_t.max

[Dmitry Olshansky]

12/29/2012 1:30 PM, Jonathan M Davis пишет:
> On Saturday, December 29, 2012 07:12:49 Mehrdad wrote:
>> On Saturday, 29 December 2012 at 02:14:22 UTC, Jonathan M Davis
>>
>> wrote:
>>> I'd be very strongly inclined to go with #4 and just say that
>>> anyone who actually cares about numbers that large should use
>>> 64-bit.
>>
>> Uhm, 64-bit?
>>
>> What about large files (> 4 GiB) on 32-bit systems?
>>
>> (Say, if a range wants to provide random access to the bytes of
>> an 8 GiB file?)
>
> You bring up a good point, but not even arrays support that, so stuff like
> std.mmfile can't possibly work with large files on 32-bit systems, not with the
> current design anyway (as it gives you an array to operate on). It may be that
> you just need to do something different if you want to operate on large files on
> 32-bit systems. I don't know.

s/array/slice
It maps a view of a part of file. Obviously one can't map parts greater 
then address space.

>
> Plenty of stuff right now in Phobos isn't going to work right now if you try
> and have a length of 64 bits on a 32-bit system. size_t is used pretty much
> everywhere. And it's going to make generic code a _lot_ less pleasant if we
> have to worry about using anything other than size_t. It's already been
> causing us problems that iota does, and we've discussed making it so that it
> doesn't. But even if we allow ulong for length and indexing on 32-bit systems,
> that's a completely different ball game from permitting BigInt.
>
> So, I'd _very_ much like to always restruct length and indices to size_t for
> ranges. It will make all of the generic handling of that stuff far more
> pleasant. But we may very well be forced to permit ulong on 32-bit systems due
> to practical concerns such as large file handling on 32-bit systems.
>

I think 32-bit version have to bite the bullet and try ulong/uint deduction.

> Oh, how I wish that 32-bit systems would just die out.
>It would make so many
> things so much easier. No such luck on that yet though, much as most PC
> processors are 64-bit now.
>

Yeah, bad sadly they are practical ;)
As 32bit is now dominating MCU world...

-- 
Dmitry Olshansky