[Development] C++20 comparisons @ Qt (was: Re: C++20 @ Qt)

[Thiago Macieira]

On Wednesday, 8 November 2023 10:05:38 PST Ivan Solovev via Development wrote:
> > I think it's acceptable for us to change the return type of a function so
> > long as it's getting a new mangling.
> 
> Well, it would be easily achievable for the template methods, but not for
> the inline hidden friend helper methods.
> As immediate solution that comes to my mind is to add a third argument to
> these methods when compiled in C++20 mode. And we could probably use
> yet another macro for that. But this will just overcomplicate the things, so
> I'm not a big fan of this idea.

Neither am I.

If we do this, the third, dummy, disambiguating parameter should simply be the 
return type itself. It's the clearest solution and makes macro definition 
simpler.

> So, you say that the compiler is smart enough to optimize away conversions
> like `std::strong_ordering -> QStrongOrdering -> std::strong_ordering`
> because the underlying integral values are the same?

Yes. Since everything is idempotent, it should just do nothing.

In practice, it looks like one of the conversions is getting clamped:
https://gcc.godbolt.org/z/n7ohc9Wo4

It might be possible to massage the code in such a way that the compiler 
realises that it is always idempotent. I haven't managed yet. We can also just 
be evil and use bit_cast:
https://gcc.godbolt.org/z/e5zefKevP

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Cloud Software Architect - Intel DCAI Cloud Engineering
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5163 bytes
Desc: not available
URL: <http://lists.qt-project.org/pipermail/development/attachments/20231108/f5dd20be/attachment.bin>