Date: Sun, 7 Dec 2025 20:11:32 +0100
niedz., 7 gru 2025 o 19:05 Jonathan Wakely via Std-Proposals
<std-proposals_at_[hidden]> napisał(a):
>
>
>
> On Sun, 7 Dec 2025, 15:04 Juan Lucas Rey, <juanlucasrey_at_[hidden]> wrote:
>>
>>
>> Also something that is confusing to me from this process is that, if the standard specifies that the return values from generate_canonical are to be smaller than 1, then why is the standard concerned with implementation problems? why does LWG 2525 even exist? If the standard says it should return values in [0,1), and implementations don’t respect that, then that’s hardly a problem of the standard right?
>>
>> That seems to be an implementation problem, and is properly addressed at the implementation level by GCC #63176
>
>
> The GCC solution is non-conforming. We are implementing p0952 as a better solution.
>
>> LLVM #18767
>
>
> This isn't fixed yet, as far as I know.
>
>
>> and MSVC STL #1074.
>
>
> The MSVC solution was to implement p0952 which means it is not conforming to the old spec, because it sometimes discards random numbers.
>
> So it's not just an implementation problem if the spec is implementable, and so implementations can only be fixed by either breaking the rules of the standard or changing the standard.
>
If we need to break implementations by changing standard, could the
standard at least require exact same results on every implementation?
Like in multiplayer video games whole simulation is run indepedly on
every machine and each one need to use diffrent compiler (like android
phone have Clang, Linux use GCC and Windows use MSVC).
If each implementation have freedom to use any algorithm as long it
preserve probability then game will desync players with code from
other compilers.
Of course this will have drawbacks as sometimes some enforced
algorithms will not be perfect and can't be updated if they have bugs.
Maybe we should have some group of algorithms that guarantee the same
results on all implementations?
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
<std-proposals_at_[hidden]> napisał(a):
>
>
>
> On Sun, 7 Dec 2025, 15:04 Juan Lucas Rey, <juanlucasrey_at_[hidden]> wrote:
>>
>>
>> Also something that is confusing to me from this process is that, if the standard specifies that the return values from generate_canonical are to be smaller than 1, then why is the standard concerned with implementation problems? why does LWG 2525 even exist? If the standard says it should return values in [0,1), and implementations don’t respect that, then that’s hardly a problem of the standard right?
>>
>> That seems to be an implementation problem, and is properly addressed at the implementation level by GCC #63176
>
>
> The GCC solution is non-conforming. We are implementing p0952 as a better solution.
>
>> LLVM #18767
>
>
> This isn't fixed yet, as far as I know.
>
>
>> and MSVC STL #1074.
>
>
> The MSVC solution was to implement p0952 which means it is not conforming to the old spec, because it sometimes discards random numbers.
>
> So it's not just an implementation problem if the spec is implementable, and so implementations can only be fixed by either breaking the rules of the standard or changing the standard.
>
If we need to break implementations by changing standard, could the
standard at least require exact same results on every implementation?
Like in multiplayer video games whole simulation is run indepedly on
every machine and each one need to use diffrent compiler (like android
phone have Clang, Linux use GCC and Windows use MSVC).
If each implementation have freedom to use any algorithm as long it
preserve probability then game will desync players with code from
other compilers.
Of course this will have drawbacks as sometimes some enforced
algorithms will not be perfect and can't be updated if they have bugs.
Maybe we should have some group of algorithms that guarantee the same
results on all implementations?
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
Received on 2025-12-07 19:11:48
