Pop Quiz what is wrong with this code?
Avrina
avrina12309412342 at gmail.com
Sun Jun 21 20:14:15 UTC 2020
On Sunday, 21 June 2020 at 19:33:47 UTC, Patrick Schluter wrote:
> On Sunday, 21 June 2020 at 13:17:54 UTC, Avrina wrote:
>> On Sunday, 21 June 2020 at 10:12:22 UTC, Patrick Schluter
>> wrote:
>>> On Saturday, 20 June 2020 at 23:36:25 UTC, Avrina wrote:
>>>> On Saturday, 20 June 2020 at 18:15:27 UTC, Steven
>>>> Schveighoffer wrote:
>>>>> On 6/20/20 12:00 PM, Danni Coy wrote:
>>>>>
>>>>>> I tried explicitly making x and y ints and I got a
>>>>>> depreciation warning.
>>>>>
>>>>> foreach(ptrdiff_t y, ref row; offsetMap)
>>>>>
>>>>> is that what you wanted?
>>>>>
>>>>> ptrdiff_t is the signed version of size_t. The complaint is
>>>>> not that you are converting from unsigned to signed, but
>>>>> that you are converting from 64-bit to 32-bit.
>>>>>
>>>>> -Steve
>>>>
>>>> Why isn't that deprecated as well? implicitly converting
>>>> from ulong to long is an error as much as ulong to uint.
>>>
>>> No. conversion of ulong to uint loses 32 times more data than
>>> conversion to long does.
>>
>> Lol, it's not linear friend.
>
> losing 1 bit vs losing 32 bits. The exponentiation is
> irrelevant.
It is when that 1 bit is worth 9223372032559808512
>> You lose around 18446744069414584319 values from ulong to
>> uint, you lose 9223372032559808512 from ulong to long. Which
>> is about 2 times less data. Which makes sense as it is
>> basically 2^64 - 2^63, so of course it would only be x2 -- not
>> x32.
>
>> Not that it should matter how much, it's a problem either way.
>
> But a much less severe one.
> Overflowing a 32 bit index on a 64 bit machine with the data
> sizes that exist today (files of more than 4GiB are not rare,
> zips, videos and databases).
> 9 223 372 032 559 808 512 is still 32768x bigger than
> 281 474 976 710 656, the biggest addressable range on x86_64.
That's an index to an array, not a file. The File api uses ulong
(as it should) and doesn't use size_t. If you are using memory
mapped files, that isn't portable and you are going to have
issues with performance. Otherwise a 32-bit index is sufficient,
you aren't ever going to have an array that big that uses up that
much memory in the system. So again, doesn't matter. There's a
reason no one has complained about this "bug" for 20 years, and
the only reason it was "discovered" was because it was
inconsistent with foreach_reverse.
More information about the Digitalmars-d
mailing list