On 23/11/2020 11:29, Lars Knoll wrote:
I've quickly implemented 3) and pushed it here. It's only missing docs.
https://codereview.qt-project.org/c/qt/qtbase/+/322900
(includes the rationale of why optional is the wrong datatype)
I like this approach.
Thanks, patch is ready for review now.
> On 23 Nov 2020, at 09:57, Giuseppe D'Angelo via Development
> wrote:
>
> Hi,
>
> On 22/09/2020 16:17, Thiago Macieira wrote:
>> And especially if there's no impact to how the user uses the API.
>>> 1)
>>> std::optional compare();
>>>
>>> 2)
>>> enum class Ordering { Less = -1, Equal = 0, Gre
Hi,
On 22/09/2020 16:17, Thiago Macieira wrote:
And especially if there's no impact to how the user uses the API.
1)
std::optional compare();
2)
enum class Ordering { Less = -1, Equal = 0, Greater = 1, Unordered = 0xff
};
Ordering compare();
3)
Implement a Qt replacement for std::partial_o
On Wednesday, 23 September 2020 13:24:24 PDT Milian Wolff wrote:
> > QAbstractItemModelPrivate::isVariantLessThan returns false for BOTH
orders:
> > isVariantLessThan(1, "hello") == false
> > isVariantLessThan("hello", 1) == false
>
> Right, sorry - I missed the part where you say "a few of the
On Mittwoch, 23. September 2020 21:12:52 CEST Thiago Macieira wrote:
> On Wednesday, 23 September 2020 06:59:16 PDT Milian Wolff wrote:
> > > 1
> > > 10
> > > 11
> > > 2
> > > 3
> > > 21
> > >
> > > A few of the above are strings and the others are numbers. It should
> > > always
> > > lexicograph
On Wednesday, 23 September 2020 06:59:16 PDT Milian Wolff wrote:
> > 1
> > 10
> > 11
> > 2
> > 3
> > 21
> >
> > A few of the above are strings and the others are numbers. It should
> > always
> > lexicographically sort or use numeric/natural sorting.
>
> This wouldn't be an issue if you sort by t
On Freitag, 18. September 2020 17:06:20 CEST Thiago Macieira wrote:
> On Friday, 18 September 2020 01:59:50 PDT Albert Astals Cid via Development
>
> wrote:
> > We have a few generic item models and proxy models that implement sorting,
> > they did so by using operator< of QVariant.
> >
> > I wan
On Tuesday, 22 September 2020 09:24:44 PDT Andrei Golubev wrote:
> Also, you can use std::optional internally in that class as an
> underlying storage for the result or/and have a conversion operator to
> std::optional if this is a much desired return type, right?
Don't use optional internally for
, right?
--
Best Regards,
Andrei
From: Development on behalf of Ville
Voutilainen
Sent: Tuesday, September 22, 2020 7:01 PM
To: Thiago Macieira
Cc: Qt development mailing list
Subject: Re: [Development] QVariant comparison in Qt6
On Tue, 22 Sep 2020 at 17:20
On Tue, 22 Sep 2020 at 17:20, Thiago Macieira wrote:
> And especially if there's no impact to how the user uses the API.
>
> > 1)
> > std::optional compare();
> >
> > 2)
> > enum class Ordering { Less = -1, Equal = 0, Greater = 1, Unordered = 0xff
> > };
> > Ordering compare();
> >
> > 3)
> > Imp
On Tuesday, 22 September 2020 06:55:35 PDT Lars Knoll wrote:
> > For internal APIs, please return just a plain int.
>
> Those compare() methods are meant to be public.
The public API does not have to be non-inline library call.
> Really? Are we now making API decisions on how well a compiler man
> On 22 Sep 2020, at 08:54, Thiago Macieira wrote:
>
> On Monday, 21 September 2020 22:55:16 PDT Lars Knoll wrote:
>> I do not want to simply return an int, as the risk that people ignore the
>> Unordered state it too big with that. So the other choice would be to add
>> an enum in the Qt name
On Monday, 21 September 2020 22:55:16 PDT Lars Knoll wrote:
> I do not want to simply return an int, as the risk that people ignore the
> Unordered state it too big with that. So the other choice would be to add
> an enum in the Qt namespace (as I need this for QMetaType as well, which
> currently
On 21 Sep 2020, at 23:02, Thiago Macieira
mailto:thiago.macie...@intel.com>> wrote:
On Monday, 21 September 2020 01:17:58 PDT Lars Knoll wrote:
On 18 Sep 2020, at 17:11, Thiago Macieira
mailto:thiago.macie...@intel.com>>
wrote:
On Friday, 18 September 2020 06:48:50 PDT Lars Knoll wrote:
std::o
On Monday, 21 September 2020 01:17:58 PDT Lars Knoll wrote:
> > On 18 Sep 2020, at 17:11, Thiago Macieira
> > wrote:
> > On Friday, 18 September 2020 06:48:50 PDT Lars Knoll wrote:
> >
> >> std::optional QVariant::compare(const QVariant &other);
> >>
> >> Would that be good enough?
> >
> >
>
On Sun, 20 Sep 2020 at 09:02, Thiago Macieira wrote:
> Hmm... I had clearly forgotten about QNX and INTEGRITY, especially the latter.
> I thought the problem with QNX was solved since they switched to Clang (or
> haven't they?).
QNX 7 AFAIK has a compiler based on GCC 8. Switching to Clang doesn
On Sun, 20 Sep 2020 at 09:06, Thiago Macieira wrote:
> > You can't write a conversion from a type you don't own to an int, or
> > vice versa. Don't fall into that trap, it's impossible
> > to dig yourself out of it.
>
> Sorry, I don't understand the issue.
>
> I'm thinking of an internal function
> On 18 Sep 2020, at 17:11, Thiago Macieira wrote:
>
> On Friday, 18 September 2020 06:48:50 PDT Lars Knoll wrote:
>> std::optional QVariant::compare(const QVariant &other);
>>
>> Would that be good enough?
>
> Why the optional?
Because there is no valid comparison we could do between a QDat
On Saturday, 19 September 2020 11:41:08 PDT Ville Voutilainen wrote:
> On Fri, 18 Sep 2020 at 21:58, Thiago Macieira
wrote:
> > Anyway, the int suffices because we only need four values:
> > equal/equivalent,>
> > less than, greater than, unordered. We can even adopt the same values:
> > //
On Saturday, 19 September 2020 11:48:11 PDT Ville Voutilainen wrote:
> Our customers report otherwise. Upgrading Qt and using it on an older
> compiler seems doable
> by a whole lotta customers. Upgrading Qt and upgrading toolchains
> seems much less doable,
> so that would be a bold expectation. T
On Sat, 19 Sep 2020 at 06:28, Thiago Macieira wrote:
> But for other things, I'm not shy about it. People can't complain that they
> can't use features that didn't exist when they wrote their application. If
> they want to use new features, it stands to reason they've just upgraded Qt.
> If they
On Fri, 18 Sep 2020 at 21:58, Thiago Macieira wrote:
> Anyway, the int suffices because we only need four values: equal/equivalent,
> less than, greater than, unordered. We can even adopt the same values:
> // less=0xff, equiv=0x00, greater=0x01, unordered=0x02
> or we can use -127 for unorder
On Friday, 18 September 2020 14:51:17 PDT André Pönitz wrote:
> > Because we should push our users to adopt new compiler versions.
>
> What kind of political agenda is that?
>
> Pushing for newer anything just means we are leaving people behind.
>
> This might be justified in some cases if there
On Fri, Sep 18, 2020 at 11:56:38AM -0700, Thiago Macieira wrote:
> On Friday, 18 September 2020 09:38:12 PDT Ville Voutilainen wrote:
> > > We should use one of the types from [1]. Yes, it's C++20; we can
> > > make our internal API return an integer that is convertible to those types
> > > in the
> What is it you need? Just some total ordering of variants? The method you
> mentioned in
> QAbstractItemModel also only does ordering for some types, otherwise falling
> back to
> strings.
I am using QVariant comparison (==, >, <) only for equal types. But not in
models. I use
it for other c
> > Has anything changed for Qt6 (especially regarding comparison of equal
> > and/or convertible types)? Is the complete deprecation still the latest
> > decision?
>
> Yes, it's changed; no, it's not deprecation.
>
> What's been removed is the conversion. Aside from the numeric types,
> compar
On Friday, 18 September 2020 09:38:12 PDT Ville Voutilainen wrote:
> > We should use one of the types from [1]. Yes, it's C++20; we can
> > make our internal API return an integer that is convertible to those
> > types in the front-end API, under #if __has_include().
> >
> > [1] https://en.cpprefe
On Fri, 18 Sep 2020 at 18:13, Thiago Macieira wrote:
>
> On Friday, 18 September 2020 06:48:50 PDT Lars Knoll wrote:
> > std::optional QVariant::compare(const QVariant &other);
> >
> > Would that be good enough?
>
> Why the optional?
>
> We should use one of the types from [1]. Yes, it's C++20; we
On Friday, 18 September 2020 01:44:36 PDT Giuseppe D'Angelo via Development
wrote:
> Il 18/09/20 02:54, Thiago Macieira ha scritto:
> > What's been removed is the conversion. Aside from the numeric types,
> > comparing two variants of different types will always result in false. If
> > you want to
On Friday, 18 September 2020 06:48:50 PDT Lars Knoll wrote:
> std::optional QVariant::compare(const QVariant &other);
>
> Would that be good enough?
Why the optional?
We should use one of the types from [1]. Yes, it's C++20; we can make
our internal API return an integer that is convertible to
On Friday, 18 September 2020 01:59:50 PDT Albert Astals Cid via Development
wrote:
> We have a few generic item models and proxy models that implement sorting,
> they did so by using operator< of QVariant.
>
> I want a way to be able to do the same in Qt6 in a way that ideally doesn't
> involve h
On Friday, 18 September 2020 01:50:50 PDT Konstantin Tokarev wrote:
> In Qt4 times comparison operators for QVariant were missing and from my
> experience main limitation was that it wasn't possible to have QVariant as
> a key in QMap without defining one manually.
Correct. That's because you shou
On 18 Sep 2020, at 14:19, Albert Astals Cid
mailto:albert.astals@kdab.com>> wrote:
[snip]
I’m not really in favour of adding an operator<() to QVariant again, as it
would need to provide some decent ordering, and that would probably cause
conflicts with operator=() that does somewhat loose
El divendres, 18 de setembre de 2020, a les 13:25:45 CEST, Lars Knoll va
escriure:
> > On 18 Sep 2020, at 11:23, Albert Astals Cid via Development
> > wrote:
> > El divendres, 18 de setembre de 2020, a les 11:00:23 CEST, André Somers va
> >
escriure:
> >
> >> On 18-09-2020 09:12, Albert Asta
> On 18 Sep 2020, at 11:23, Albert Astals Cid via Development
> wrote:
>
> El divendres, 18 de setembre de 2020, a les 11:00:23 CEST, André Somers va
> escriure:
>> On 18-09-2020 09:12, Albert Astals Cid via Development wrote:
>>> El divendres, 18 de setembre de 2020, a les 2:54:53 CEST, Thia
El divendres, 18 de setembre de 2020, a les 11:00:23 CEST, André Somers va
escriure:
> On 18-09-2020 09:12, Albert Astals Cid via Development wrote:
> > El divendres, 18 de setembre de 2020, a les 2:54:53 CEST, Thiago Macieira
> > va>
> > escriure:
> >> On Thursday, 17 September 2020 16:15:47 PDT
On Freitag, 18. September 2020 10:28:06 CEST Albert Astals Cid via Development
wrote:
> El divendres, 18 de setembre de 2020, a les 10:22:16 CEST, Lars Knoll va
escriure:
> > Sorting and equality are two different things. QVariant has never
> > supported
> > a lessThan operator.
>
> Yes, it has
Il 18/09/20 10:22, Lars Knoll ha scritto:
Sorting and equality are two different things. QVariant has never
supported a lessThan operator.
That's not accurate. Q5Variant has operator<, and Q5MetaType allowed to
register comparators (op== and op<) for a user type. I don't know how
much softw
On 18-09-2020 09:12, Albert Astals Cid via Development wrote:
El divendres, 18 de setembre de 2020, a les 2:54:53 CEST, Thiago Macieira va
escriure:
On Thursday, 17 September 2020 16:15:47 PDT Bernhard Lindner wrote:
Hi!
There was a discussion about the decision to deprecate (remove?) QVarian
El divendres, 18 de setembre de 2020, a les 10:37:36 CEST, Lars Knoll va
escriure:
> > On 18 Sep 2020, at 10:28, Albert Astals Cid
> > wrote:
> > El divendres, 18 de setembre de 2020, a les 10:22:16 CEST, Lars Knoll va
> > escriure:
>
> >> Sorting and equality are two different things. QVarian
18.09.2020, 11:40, "Lars Knoll" :
>> On 18 Sep 2020, at 10:28, Albert Astals Cid
>> wrote:
>>
>> El divendres, 18 de setembre de 2020, a les 10:22:16 CEST, Lars Knoll va
>> escriure:
>>> Sorting and equality are two different things. QVariant has never supported
>>> a lessThan operator.
>>
Il 18/09/20 02:54, Thiago Macieira ha scritto:
What's been removed is the conversion. Aside from the numeric types, comparing
two variants of different types will always result in false. If you want to
compare across types, convert one to the other's type or to a common third
type. You know what
> On 18 Sep 2020, at 10:28, Albert Astals Cid
> wrote:
>
> El divendres, 18 de setembre de 2020, a les 10:22:16 CEST, Lars Knoll va
> escriure:
>> Sorting and equality are two different things. QVariant has never supported
>> a lessThan operator.
>
> Yes, it has
>
> https://code.qt.io/cgit/
El divendres, 18 de setembre de 2020, a les 10:22:16 CEST, Lars Knoll va
escriure:
> Sorting and equality are two different things. QVariant has never supported
> a lessThan operator.
Yes, it has
https://code.qt.io/cgit/qt/qtbase.git/tree/src/corelib/kernel/qvariant.h?h=5.15#n467
Cheers,
Albe
On 18 Sep 2020, at 09:12, Albert Astals Cid via Development
mailto:development@qt-project.org>> wrote:
El divendres, 18 de setembre de 2020, a les 2:54:53 CEST, Thiago Macieira va
escriure:
On Thursday, 17 September 2020 16:15:47 PDT Bernhard Lindner wrote:
Hi!
There was a discussion about the
On Freitag, 18. September 2020 02:54:53 CEST Thiago Macieira wrote:
> On Thursday, 17 September 2020 16:15:47 PDT Bernhard Lindner wrote:
> > Hi!
> >
> > There was a discussion about the decision to deprecate (remove?) QVariant
> > comparison (<,>) in Qt6 completely.
> >
> > Has anything changed
El divendres, 18 de setembre de 2020, a les 2:54:53 CEST, Thiago Macieira va
escriure:
> On Thursday, 17 September 2020 16:15:47 PDT Bernhard Lindner wrote:
> > Hi!
> >
> > There was a discussion about the decision to deprecate (remove?) QVariant
> > comparison (<,>) in Qt6 completely.
> >
> > H
On Thursday, 17 September 2020 16:15:47 PDT Bernhard Lindner wrote:
> Hi!
>
> There was a discussion about the decision to deprecate (remove?) QVariant
> comparison (<,>) in Qt6 completely.
>
> Has anything changed for Qt6 (especially regarding comparison of equal
> and/or convertible types)? Is
Hi!
There was a discussion about the decision to deprecate (remove?) QVariant
comparison (<,>)
in Qt6 completely.
Has anything changed for Qt6 (especially regarding comparison of equal and/or
convertible
types)? Is the complete deprecation still the latest decision?
--
Best Regards,
Bernhar
49 matches
Mail list logo
