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).