foreach counter now must be size_t ?
Rubn
where at is.this
Thu Feb 7 01:10:25 UTC 2019
On Wednesday, 6 February 2019 at 21:23:20 UTC, H. S. Teoh wrote:
> On Wed, Feb 06, 2019 at 08:59:14PM +0000, Rubn via
> Digitalmars-d wrote:
>> On Wednesday, 6 February 2019 at 06:27:27 UTC, Patrick
>> Schluter wrote:
> [...]
>> > Memory mapping archives and video files can easily get
>> > beyond 32 bits. It's not because you never noticed that
>> > there aren't people out there doing that every day.
> [...]
>> I never knew arrays were files, thanks for the tip.
>
> As you may know, mmap() turns files into arrays (see
> std.mmfile). You
> access it just like an array, and the OS maps it to the file
> for you.
>
> You wouldn't want somebody to pass the array returned by an
> mmap() call to your code that assumes arrays cannot have length
> larger than 32-bits -- you'd run into wraparound bugs.
Not everyone is writing generic code. Especially in performance
critical code.
Like I was saying, this is one those very rare use cases anyways.
And AGAIN if you have a memory mapped file in a 32-bit
executable, this will not function.
Lol man the implementation of mmfile. The interface all uses
ulong but then it casts everything to size_t, that's a minefield
on a 32-bit system. Good luck accessing a > 4GB file with that.
> Just because the array has a huge size doesn't necessarily mean
> you need that much RAM to hold it. The OS pages parts of it
> in/out as you access it.
Which will be extremely slow. That might be fine for testing
something but you'll be better off writing your own code to
handle processing that much data in a way that is most efficient
for whatever it is you are doing.
More information about the Digitalmars-d
mailing list