Re: [lmi] [lmi-commits] odd/gpt e293170 1/5: Add an equality operator

[Greg Chicares]

On 4/27/21 9:46 PM, Vadim Zeitlin wrote:
> On Tue, 27 Apr 2021 21:26:23 +0000 Greg Chicares <gchicares@sbcglobal.net> 
> wrote:
[...]
> GC> As I read SD-6, an implementation is free to define any of these
> GC> macros to be zero, even if it doesn't support the corresponding
> GC> feature.
> 
>  To be honest, I'm not sure if this is the correct reading, but my main
> point is that in practice the only 3 existing C++20 implementations don't
> do this and I consider it extremely unlikely that any implementation
> appearing in the future would make a choice to be intentionally
> incompatible with the existing ones in such a basic way.

Okay, in future I'll just test
  #if defined __cpp_whatever
Surely other people are doing that, too, so it will have become
established practice that compiler vendors will avoid breaking.

Of course, I won't change this commit because it's on a temporary
branch that won't get merged until after the test becomes obsolete
It's in the process of obsolescing as we speak as I upgrade from
gcc-8 to gcc-10. The wine-induced changes in measured speed (which
are recorded in a commit that I haven't pushed yet) would be
astonishing if we didn't expect them for the reasons explained here:
  https://lists.nongnu.org/archive/html/lmi/2020-09/msg00039.html

Before merging your std::filesystem work, I still have to deal
with some small numerical regressions (with i686-w64-mingw32) that
I hadn't expected. BTW, they seem to arise in large part because
some intermediate calculations probably should be performed with
class currency rather than double, but haven't yet been changed
to currency. I'd rather address those problems while keeping the
architecture constant and upgrading the compiler version, because
if I can find a way to eliminate them by using currency more
widely, that should make the architecture change much easier,
especially because the architecture change will cause different
hardware to be used for most floating-point calculations.