Re: [Development] C++20 comparisons @ Qt (was: Re: C++20 @ Qt)
On Monday, 13 November 2023 09:38:43 PST Ivan Solovev via Development wrote: > I really do not want to miss yet another FF. Given that this is an API that is going to stay with us for at least a decade, I'd rather get it right than getting it soon. -- Thiago Macieira - thiago.macieira (AT) intel.com Cloud Software Architect - Intel DCAI Cloud Engineering smime.p7s Description: S/MIME cryptographic signature -- Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] C++20 comparisons @ Qt (was: Re: C++20 @ Qt)
On Monday, 13 November 2023 09:15:10 PST Marc Mutz via Development wrote: > On 13.11.23 17:15, Thiago Macieira wrote: > > On Monday, 13 November 2023 01:34:08 PST Ivan Solovev via Development wrote: > > I don't think this minor thing is worth the hassle. It uglifies our API > > for > > little gain. > > What, specifically, is ugly? That we have two Qt partial_ordering types? Yes. > Anyway, that's subjective. Objectively, it breaks the impasse between > full efficiency in future-looking C++20 builds and Qt BC guarantees. We're not losing anything either because the only case where this would be necessary is if we needed to return a std::partial_order result from a non- inline function that is, in turn, calling the non-inline QMetaType and/or QVariant functions. We have zero of those today and aren't likely to get any of them, probably ever. Some user code might, but I find it unlikely too. It could happen if the user decided to wrap a QVariant in a larger type that did have a three-way out-of- line comparison function. Everywhere else, the optimiser will do the right thing. > Given that Qt 7.0 is many years away, I don't think it's too much to ask > to go the extra mile and remove the overhead. We seem to agree how to do > it technically, and it won't be on you to implement all this, but on > Ivan and me. I think I speak for Ivan, too, if I say that we'd rather > today than tomorrow see this stuff merged. The next FF is already > approaching again. It could be done, but I just don't see the value. If we do it, please come up with proper Qt-style class names for it. No snake_case. -- Thiago Macieira - thiago.macieira (AT) intel.com Cloud Software Architect - Intel DCAI Cloud Engineering smime.p7s Description: S/MIME cryptographic signature -- Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] C++20 comparisons @ Qt (was: Re: C++20 @ Qt)
Marc wrote:
> I think I speak for Ivan, too, if I say that we'd rather
> today than tomorrow see this stuff merged. The next FF is already
> approaching again.
Right! This now seems to be the only thing blocking the whole
chain, and I think Marc's proposal solves all the issues.
I really do not want to miss yet another FF.
Best regards,
Ivan
From: Development on behalf of Marc Mutz
via Development
Sent: Monday, November 13, 2023 6:15 PM
To: development@qt-project.org
Subject: Re: [Development] C++20 comparisons @ Qt (was: Re: C++20 @ Qt)
On 13.11.23 17:15, Thiago Macieira wrote:
> On Monday, 13 November 2023 01:34:08 PST Ivan Solovev via Development wrote:
>> Thiago wrote:
>>> The problem is that QPartialOrdering::Unordered has been in our ABI since
>>> 6.1 and we can't change that any more.
>>
>> Well, Marc already suggested a solution for this problem.
>> Let's just introduce Qt::{strong,weak,partial}_ordering and deprecate
>> QPartialOrdering in favor of the new types.
>>
>> We need to provide conversion between QPartialOrdering and
>> Qt::partial_ordering, but the new types can be fully BC with std.
>
> I don't think this minor thing is worth the hassle. It uglifies our API for
> little gain.
What, specifically, is ugly? That we have two Qt partial_ordering types?
Anyway, that's subjective. Objectively, it breaks the impasse between
full efficiency in future-looking C++20 builds and Qt BC guarantees.
Given that Qt 7.0 is many years away, I don't think it's too much to ask
to go the extra mile and remove the overhead. We seem to agree how to do
it technically, and it won't be on you to implement all this, but on
Ivan and me. I think I speak for Ivan, too, if I say that we'd rather
today than tomorrow see this stuff merged. The next FF is already
approaching again.
Thanks,
Marc
--
Marc Mutz
Principal Software Engineer
The Qt Company
Erich-Thilo-Str. 10 12489
Berlin, Germany
www.qt.io
Geschäftsführer: Mika Pälsi, Juha Varelius, Jouni Lintunen
Sitz der Gesellschaft: Berlin,
Registergericht: Amtsgericht Charlottenburg,
HRB 144331 B
--
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
--
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
Re: [Development] C++20 comparisons @ Qt (was: Re: C++20 @ Qt)
On 13.11.23 17:15, Thiago Macieira wrote:
> On Monday, 13 November 2023 01:34:08 PST Ivan Solovev via Development wrote:
>> Thiago wrote:
>>> The problem is that QPartialOrdering::Unordered has been in our ABI since
>>> 6.1 and we can't change that any more.
>>
>> Well, Marc already suggested a solution for this problem.
>> Let's just introduce Qt::{strong,weak,partial}_ordering and deprecate
>> QPartialOrdering in favor of the new types.
>>
>> We need to provide conversion between QPartialOrdering and
>> Qt::partial_ordering, but the new types can be fully BC with std.
>
> I don't think this minor thing is worth the hassle. It uglifies our API for
> little gain.
What, specifically, is ugly? That we have two Qt partial_ordering types?
Anyway, that's subjective. Objectively, it breaks the impasse between
full efficiency in future-looking C++20 builds and Qt BC guarantees.
Given that Qt 7.0 is many years away, I don't think it's too much to ask
to go the extra mile and remove the overhead. We seem to agree how to do
it technically, and it won't be on you to implement all this, but on
Ivan and me. I think I speak for Ivan, too, if I say that we'd rather
today than tomorrow see this stuff merged. The next FF is already
approaching again.
Thanks,
Marc
--
Marc Mutz
Principal Software Engineer
The Qt Company
Erich-Thilo-Str. 10 12489
Berlin, Germany
www.qt.io
Geschäftsführer: Mika Pälsi, Juha Varelius, Jouni Lintunen
Sitz der Gesellschaft: Berlin,
Registergericht: Amtsgericht Charlottenburg,
HRB 144331 B
--
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
Re: [Development] C++20 comparisons @ Qt (was: Re: C++20 @ Qt)
On Monday, 13 November 2023 01:34:08 PST Ivan Solovev via Development wrote:
> Thiago wrote:
> > The problem is that QPartialOrdering::Unordered has been in our ABI since
> > 6.1 and we can't change that any more.
>
> Well, Marc already suggested a solution for this problem.
> Let's just introduce Qt::{strong,weak,partial}_ordering and deprecate
> QPartialOrdering in favor of the new types.
>
> We need to provide conversion between QPartialOrdering and
> Qt::partial_ordering, but the new types can be fully BC with std.
I don't think this minor thing is worth the hassle. It uglifies our API for
little gain.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Cloud Software Architect - Intel DCAI Cloud Engineering
smime.p7s
Description: S/MIME cryptographic signature
--
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
Re: [Development] C++20 comparisons @ Qt (was: Re: C++20 @ Qt)
Thiago wrote:
> The problem is that QPartialOrdering::Unordered has been in our ABI since 6.1
> and we can't change that any more.
Well, Marc already suggested a solution for this problem.
Let's just introduce Qt::{strong,weak,partial}_ordering and deprecate
QPartialOrdering
in favor of the new types.
We need to provide conversion between QPartialOrdering and
Qt::partial_ordering, but
the new types can be fully BC with std.
See the details in https://bugreports.qt.io/browse/QTBUG-118913
Thanks,
Ivan
From: Development on behalf of Thiago
Macieira
Sent: Friday, November 10, 2023 6:12 PM
To: development@qt-project.org
Subject: Re: [Development] C++20 comparisons @ Qt (was: Re: C++20 @ Qt)
On Friday, 10 November 2023 00:11:11 PST Marc Mutz via Development wrote:
> On 09.11.23 16:28, Thiago Macieira wrote:
> > But if the symbols are globally visible (ELF visibility STV_DEFAULT)
>
> That counts as "exported", doesn't it?
Yes.
> Which leaves us with:
> - MSVC doesn't export anything by default; inline functions are,
> however, exported when the surrounding class is wholly exported
> - on all other platforms, all functions are by default "exported", but
> we emulate MSVC on those platforms by changing the default visibility to
> hidden, incl. for inline functions
>
> And my previous questions:
>
> - do our BC guarantees exist at all in the absence of
> `-fvisibility=hidden -fvisibility-inlines-hidden`?
Yes, we have to, because we don't control how the user's library is being
compiled.
> - does making the Qt and std::ordering types BC with each other not
> solve the problem in this case, too?
It does. We should really do that for Qt 7.0.
The problem is that QPartialOrdering::Unordered has been in our ABI since 6.1
and we can't change that any more.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Cloud Software Architect - Intel DCAI Cloud Engineering
--
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
