[Development] C++20 comparisons @ Qt (was: Re: C++20 @ Qt)
thiago.macieira at intel.com
Thu Nov 3 18:38:31 CET 2022
On Thursday, 3 November 2022 09:48:49 PDT Marc Mutz via Development wrote:
> Hi Thiago,
> On 03.11.22 16:17, Thiago Macieira wrote:
> > the devil will be in the details because of QT_REMOVED_SINCE.
> What, specifically, are you thinking about here? For the sketched
> approach to work, no new relational operator must be exported, because
> we need to keep BC between C++17 and C++20 builds. If existing ones are,
> we'll need to QT_REMOVED_SINCE them. Where's the problem?
Nothing specific. It could be nothing, it could be simple ugliness that / code
readability, or there may be some classes we can't move the operators away for
at all: there was one case we couldn't remove / move away because the method
was inline and was used by QtCore itself. We won't know until we try.
> > For some classes, we could postpone changing anything until C++20 is
> > required.
> You lost me there. Why do you think so? Because of the sentence above?
> Requiring C++20 won't be a BC break, so we'd still have all the old
> exported relational operators to QT_REMOVED_SINCE.
A simple question of code readability. If it's not that important and it makes
the code significantly uglier, we can simply postpone until it's not ugly.
> > Meanwhile, we have qcompare.h.
> Here, too, I feel lost. I'm struggling to see what a NIH
> std::partial_ordering w/o the weak and strong counterparts and w/o op<=>
> language support could achieve, except another vocabulary type mismatch.
> Can you elaborate?
We can use it until we can depend on C++20. Like QSpan, that's why it's there.
Or the methods can simply return int, like I intended in QCborValue.
> Meanwhile, in a Jira comment, Eddy discovered a potential problem with
> partial_ordering::unordered: we have a lot of types that have
> std::optional folded into them (isNull/isValid) and, if they're ordered,
> they need to have decided on a total order, ie. incl. for invalid/null
> ones (QDateTime sorts invalid before valid e.g.). These types' op<=>
> could now return unordered for invalid values, but that would change the
> semantics of the op< derived from it vis a vis the existing op<.
What's the recommendation? Create a total order where null < empty < any non-
empty, or use partial ordering?
Thiago Macieira - thiago.macieira (AT) intel.com
Cloud Software Architect - Intel DCAI Cloud Engineering
More information about the Development