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.
