[Development] QVariant comparison in Qt6

Andrei Golubev andrei.golubev at qt.io
Tue Sep 22 18:24:44 CEST 2020

Tend to agree with Ville, it would be easier to adopt std::partial_ordering with a proper class in place.
Also, you can use std::optional<int> internally in that class as an underlying storage for the result or/and have a conversion operator to std::optional<int> if this is a much desired return type, right?

Best Regards,
From: Development <development-bounces at qt-project.org> on behalf of Ville Voutilainen <ville.voutilainen at gmail.com>
Sent: Tuesday, September 22, 2020 7:01 PM
To: Thiago Macieira <thiago.macieira at intel.com>
Cc: Qt development mailing list <development at qt-project.org>
Subject: Re: [Development] QVariant comparison in Qt6

On Tue, 22 Sep 2020 at 17:20, Thiago Macieira <thiago.macieira at intel.com> wrote:
> And especially if there's no impact to how the user uses the API.
> > 1)
> > std::optional<int> compare();
> >
> > 2)
> > enum class Ordering { Less = -1, Equal = 0, Greater = 1, Unordered = 0xff
> > };
> >  Ordering compare();
> >
> > 3)
> > Implement a Qt replacement for std::partial_ordering (could use the std
> > stuff if C++ 20 is available) and use that.
> I'd rather stay simple and allow extending for <compare> where more details
> are necessary.
> For that, I think #1.

If this is an API function that users call, make it (2) but make it a
class, not an enum class.
You can then later write a conversion operator that converts the
result to std::partial_ordering.

if this is a private function that no user sees directly, then 1/2 are
both fine. The class I mention
above basically is a Qt replacement for std::partial_ordering, of course.
Development mailing list
Development at qt-project.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20200922/a47b44d3/attachment-0001.html>

More information about the Development mailing list