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