Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c++ > #82711

Re: A counterintuitive breaking change related to new comparisons

Show all headers | View raw

On 1/3/2022 11:24 PM, Andrey Tarasevich wrote:
> On 1/3/2022 9:48 AM, Andrey Tarasevich wrote:
>> A colleague discovered that switching from `-stc=c++17` to 
>> `-std=c++20` in their project resulted in a different behavior from 
>> some associative containers. A bit of research allowed to narrow down 
>> the culprit to what can be demonstrated by the following minimalist 
>> example
>>
>>    #include <iostream>
>>
>>    struct S
>>    {
>>      char c;
>>
>>      operator const char *() const { return &c; }
>>
>>      friend bool operator <(const S& lhs, const S& rhs)
>>        { return lhs.c < rhs.c; }
>>    };
>>
>>    int main()
>>    {
>>      std::pair<int, S> p1{}, p2{};
>>      std::cout << (p1 < p2) << (p2 < p1) << std::endl;
>>    }
>>
>> C++17 compilers output `00`. C++20 compilers output `01` (or, perhaps, 
>> `10`).
>>
>> The obvious guess is that comparisons for `std::pair` work differently 
>> in C++20 after the introduction of `<=>`. And indeed, the `<=>` 
>> operator for `std::pair` in this case ignores the user-defined `<` and 
>> instead opts for raw pointer comparison through conversion to `const 
>> char *`. This is a rather surprising and counterintuitive breaking 
>> change, to put it mildly...
>>
>> If we remove the user-defined conversion to `const char *`, C++20 will 
>> use the user-defined `<` and also output `00`.
>>
>> The above results were obtained with GCC. Clang 10 outputs `00` even 
>> in `-std=c++20` mode, but Clang 11 and later output `01`.
> 
> To take out of the picture the irrelevant matter of undefined pointer 
> comparison, here's another example
> 
>    #include <iostream>
> 
>    struct S
>    {
>      int a;
> 
>      S(int a) : a(a) {}
> 
>      operator int() const { return a; }
> 
>      friend bool operator <(const S& lhs, const S& rhs)
>        { return lhs.a > rhs.a; }
>    };
> 
>    int main()
>    {
>      std::pair<int, S> p1{ 0, 1 }, p2{ 0, 2 };
>      std::cout << (p1 < p2) << (p2 < p1) << std::endl;
>    }
> 
> This program outputs `01` in C++17 mode (and earlier)
> http://coliru.stacked-crooked.com/a/98f0b6b57e9caf45
> 
> but outputs `10` in C++20 mode
> http://coliru.stacked-crooked.com/a/3f8c3e96cd39f596
> 
> In C++17 the user-defined comparison operator is used. In C++20 
> conversion to `int` and subsequent comparison of `int`s is used.
> 

That's really odd indeed.
Are you sure that is is the C++20 standard that mandates this behavior?
I wouldn't be surprised if this were a plain bug in the implementation - 
possibly related with the changes that you mention above - but still a bug.

In fact, gcc 11.2 with plain -std=c++20 gives '01':

https://www.godbolt.org/z/rEjfehdnY

Back to comp.lang.c++ | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

A counterintuitive breaking change related to new comparisons Andrey Tarasevich <andreytarasevich@hotmail.com> - 2022-01-03 09:48 -0800
  Re: A counterintuitive breaking change related to new comparisons Chris Vine <chris@cvine--nospam--.freeserve.co.uk> - 2022-01-03 21:06 +0000
    Re: A counterintuitive breaking change related to new comparisons Andrey Tarasevich <andreytarasevich@hotmail.com> - 2022-01-03 14:13 -0800
      Re: A counterintuitive breaking change related to new comparisons Chris Vine <chris@cvine--nospam--.freeserve.co.uk> - 2022-01-04 00:23 +0000
        Re: A counterintuitive breaking change related to new comparisons Andrey Tarasevich <andreytarasevich@hotmail.com> - 2022-01-03 16:33 -0800
          Re: A counterintuitive breaking change related to new comparisons Juha Nieminen <nospam@thanks.invalid> - 2022-01-04 08:27 +0000
            Re: A counterintuitive breaking change related to new comparisons "Alf P. Steinbach" <alf.p.steinbach@gmail.com> - 2022-01-04 17:24 +0100
            Re: A counterintuitive breaking change related to new comparisons Andrey Tarasevich <andreytarasevich@hotmail.com> - 2022-01-04 10:26 -0800
        Re: A counterintuitive breaking change related to new comparisons Chris Vine <chris@cvine--nospam--.freeserve.co.uk> - 2022-01-04 00:39 +0000
  Re: A counterintuitive breaking change related to new comparisons Andrey Tarasevich <andreytarasevich@hotmail.com> - 2022-01-03 14:24 -0800
    Re: A counterintuitive breaking change related to new comparisons "Alf P. Steinbach" <alf.p.steinbach@gmail.com> - 2022-01-03 23:55 +0100
    Re: A counterintuitive breaking change related to new comparisons Manfred <noname@add.invalid> - 2022-01-04 00:56 +0100
      Re: A counterintuitive breaking change related to new comparisons Manfred <noname@add.invalid> - 2022-01-04 00:59 +0100
      Re: A counterintuitive breaking change related to new comparisons Andrey Tarasevich <andreytarasevich@hotmail.com> - 2022-01-03 16:59 -0800
        Re: A counterintuitive breaking change related to new comparisons Chris Vine <chris@cvine--nospam--.freeserve.co.uk> - 2022-01-04 01:27 +0000
        Re: A counterintuitive breaking change related to new comparisons Öö Tiib <ootiib@hot.ee> - 2022-01-04 14:49 -0800
          Re: A counterintuitive breaking change related to new comparisons Öö Tiib <ootiib@hot.ee> - 2022-01-04 15:16 -0800
          Re: A counterintuitive breaking change related to new comparisons Andrey Tarasevich <andreytarasevich@hotmail.com> - 2022-01-05 09:06 -0800
  Re: A counterintuitive breaking change related to new comparisons "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2022-01-03 18:51 -0800
  Re: A counterintuitive breaking change related to new comparisons wij <wyniijj@gmail.com> - 2022-01-04 03:53 -0800
    Re: A counterintuitive breaking change related to new comparisons wij <wyniijj@gmail.com> - 2022-01-04 21:59 -0800

csiph-web