public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug libstdc++/102589] New: spaceship: std::map does not use specialised operator< for value
@ 2021-10-04  9:47 gjasny at googlemail dot com
  2021-10-04 10:31 ` [Bug libstdc++/102589] " redi at gcc dot gnu.org
  2021-10-04 10:39 ` redi at gcc dot gnu.org
  0 siblings, 2 replies; 3+ messages in thread
From: gjasny at googlemail dot com @ 2021-10-04  9:47 UTC (permalink / raw)
  To: gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102589

            Bug ID: 102589
           Summary: spaceship: std::map does not use specialised operator<
                    for value
           Product: gcc
           Version: 11.2.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: libstdc++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: gjasny at googlemail dot com
  Target Milestone: ---

Created attachment 51546
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51546&action=edit
Testcase

Hello,

I stumbled over this issue when porting a code base from C++17 to C++20. Both:
GNU libstdc++ as well as MSVC STL show the unexpected behaviour. Libc++ seems
to do the right thing.

Describe the bug

Compiling the test case with C++17 works as expected whereas compiling it with
C++20 makes the test assumption fail.

The reason is that for C++ 20 builds the specialised operator<(const FooPtr&
left, const FooPtr& right) is not picked up. Instead the default operator<=>
for std::shared_ptr is used which only compares the raw pointers and not the
content they point to.

Expected behavior

I'd expect that with C++17 and C++20 the STL would prefer the specialised
operator<(const FooPtr& left, const FooPtr& right) over the synthesised <=>
one. That would also align with the strong backwards compatibilities C++
strives for.

GCC version

g++-11 (Debian 11.2.0-8) 11.2.0

Links

Microsoft STL Issue: https://github.com/microsoft/STL/issues/2234
Debian Sid based reproducer: https://github.com/gjasny/map-spaceship-testcase
Godbolt: https://godbolt.org/z/objPnjo84


Thanks,
Gregor

^ permalink raw reply	[flat|nested] 3+ messages in thread

* [Bug libstdc++/102589] spaceship: std::map does not use specialised operator< for value
  2021-10-04  9:47 [Bug libstdc++/102589] New: spaceship: std::map does not use specialised operator< for value gjasny at googlemail dot com
@ 2021-10-04 10:31 ` redi at gcc dot gnu.org
  2021-10-04 10:39 ` redi at gcc dot gnu.org
  1 sibling, 0 replies; 3+ messages in thread
From: redi at gcc dot gnu.org @ 2021-10-04 10:31 UTC (permalink / raw)
  To: gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102589

Jonathan Wakely <redi at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|---                         |INVALID
             Status|UNCONFIRMED                 |RESOLVED

--- Comment #1 from Jonathan Wakely <redi at gcc dot gnu.org> ---
(In reply to Gregor Jasny from comment #0)
> I stumbled over this issue when porting a code base from C++17 to C++20.
> Both: GNU libstdc++ as well as MSVC STL show the unexpected behaviour.
> Libc++ seems to do the right thing.

Probably because it doesn't implement <=> support in the standard library at
all. Libstdc++ and MSVC do.

> Describe the bug
> 
> Compiling the test case with C++17 works as expected whereas compiling it
> with C++20 makes the test assumption fail.

The assumption is wrong.

> The reason is that for C++ 20 builds the specialised operator<(const FooPtr&
> left, const FooPtr& right) is not picked up. Instead the default operator<=>
> for std::shared_ptr is used which only compares the raw pointers and not the
> content they point to.

This is the correct behaviour.

> Expected behavior
> 
> I'd expect that with C++17 and C++20 the STL would prefer the specialised
> operator<(const FooPtr& left, const FooPtr& right) over the synthesised <=>
> one. That would also align with the strong backwards compatibilities C++
> strives for.

No. Comparing the two std::map objects has to use <=> because there is no < for
std::map in C++20, so you get a synthesized < from the <=> for std::map. And
obviously <=> for std::map is going to try to use <=> for its elements. So it
uses <=> for std::pair which uses <=> for its members, so it uses <=> for
std::shared_ptr. The only < comparison that happens is the one for std::map,
after that everything is a three-way comparison.

^ permalink raw reply	[flat|nested] 3+ messages in thread

* [Bug libstdc++/102589] spaceship: std::map does not use specialised operator< for value
  2021-10-04  9:47 [Bug libstdc++/102589] New: spaceship: std::map does not use specialised operator< for value gjasny at googlemail dot com
  2021-10-04 10:31 ` [Bug libstdc++/102589] " redi at gcc dot gnu.org
@ 2021-10-04 10:39 ` redi at gcc dot gnu.org
  1 sibling, 0 replies; 3+ messages in thread
From: redi at gcc dot gnu.org @ 2021-10-04 10:39 UTC (permalink / raw)
  To: gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102589

--- Comment #2 from Jonathan Wakely <redi at gcc dot gnu.org> ---
Overloading < for shared_ptr like that is a bit questionable anyway.

You can use std::lexicographical_compare with a custom comparison function if
you want the custom less-than behaviour:

    if (std::lexicographical_compare(largerMap.begin(), largerMap.end(),
smallerMap.begin(), smallerMap.end(), [](const auto& l, const auto& r) { return
l.first < r.first || (l.first == r.first && *l.second < *r.second); }))

This does the same thing in C++17 and C++20.

^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2021-10-04 10:39 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-10-04  9:47 [Bug libstdc++/102589] New: spaceship: std::map does not use specialised operator< for value gjasny at googlemail dot com
2021-10-04 10:31 ` [Bug libstdc++/102589] " redi at gcc dot gnu.org
2021-10-04 10:39 ` redi at gcc dot gnu.org

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).