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
