> I would like to fix
> QASV(char) to mean QASV(QChar(char)), not redefine char literals as
> UTF-8 and break many more users (QASV is relatively new; QChar(char) and
> QString::arg(char) are there since before Qt 4).
>
> What do you think?
+1 for this proposal.
I do not think that QASV(char)
velopment@qt-project.org
Subject: Re: [Development] std::format support for Qt string types
On Friday 7 June 2024 01:53:55 GMT-7 Ivan Solovev via Development wrote:
> Note that currently the standard does not allow to mix char and wide char
> strings, so something like this will not work:
&g
Hi
> I think we should conceptually separate formatting from printing on a
> terminal. std::format isn't _just_ for printing on terminals
I agree. But the same question about encoding to be used is still valid here.
> What do you mean by "readable" here?
I was mostly thinking about "readable
Hi,
I'm now working on introducing std::format support for some of the Qt types.
I decided to start with the variety of Qt string types, and I have some open
question regarding the implementation that I want to discuss.
First, I'd like to give a very short summary of my understanding of how
+1
Best regards,
Ivan
From: Development on behalf of Alexey
Edelev via Development
Sent: Thursday, May 30, 2024 8:46 AM
To: development@qt-project.org
Subject: [Development] Nominating Dennis Oberst for approver rights
Hi all,
I would like to nominate
> The ABI functions can return one of these other types:
> bool (for equality comparisons)
> int (for non-partial ordering)
> QPartialOrdering (for partial ordering)
IIUC, returning QPartialOrdering is exactly what we want to avoid, due to the
std::partial_ordering -> QPartialOrdering (and
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.
>>
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
Marc wrote:
> Why do you say it only applies to partial ordering? Do we already match
> the values, other than that of std::partial_ordering::unordered?
Yes, we do.
Thiago wrote:
> We can also just be evil and use bit_cast
Why is that evil? Reading about std::bit_cast, this can be an option, if
> 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
+1
--
Ivan Solovev
Senior Software Engineer
The Qt Company GmbH
Erich-Thilo-Str. 10
12489 Berlin, Germany
ivan.solo...@qt.io
www.qt.io
Geschäftsführer: Mika Pälsi,
Juha Varelius, Jouni Lintunen
Sitz der Gesellschaft: Berlin,
Registergericht: Amtsgericht
Hi,
I'd like to discuss one more topic regarding the C++20 comparison.
Can we allow an `auto` return type in helper functions and the three-way
comparison implementation for the built-in types?
The idea is that these methods can return `Q*Ordering` types in C++17 mode, and
`std::*_ordering`
So, let me give another update.
The chaing ending in https://codereview.qt-project.org/c/qt/qtbase/+/508464
passed a full pre-check in the CI.
It implements the macros in terms of helper functions ``comparesEqual()``
and ``compareThreeWay()``.
The macros are documented as internal for now.
It
144331 B
From: Development on behalf of Ivan
Solovev via Development
Sent: Thursday, September 21, 2023 11:10 AM
To: development@qt-project.org
Subject: Re: [Development] C++20 comparisons @ Qt (was: Re: C++20 @ Qt)
> See my other email: the (1) is not discovera
tr. 10
12489 Berlin, Germany
ivan.solo...@qt.io
www.qt.io
Geschäftsführer: Mika Pälsi,
Juha Varelius, Jouni Lintunen
Sitz der Gesellschaft: Berlin,
Registergericht: Amtsgericht
Charlottenburg, HRB 144331 B
From: Development on behalf of Ivan
Solovev via Devel
> I have just rebased the chain on top of the latest dev and fixed the issue
> with qfloat16 and -Wfloat-equal.
> Now it builds fine for me locally on Linux with GCC. Started a full pre-check
> in the CI to test other configurations.
> I'll keep an eye on the pre-check results and try to fix any
opment] C++20 comparisons @ Qt (was: Re: C++20 @ Qt)
On 20.09.23 14:42, Ivan Solovev via Development wrote:
> We have deprecated qSwap()
FTR:
We did _not_ deprecate qSwap(). We banned it from inline Qt code when we
know we can use one of the other ways:
- lhs.swap(rhs);
- std::s
Hi,
> Given the state of https://codereview.qt-project.org/c/qt/qtbase/+/481410/3
> right now (needs rebase, doesn’t build with either C++17 or C++20 for me on
> macOS with apple’s clang)
I have just rebased the chain on top of the latest dev and fixed the issue with
qfloat16 and
will not consider ADL.
If you have more, let's hear it.
Thanks,
Marc
On 17.08.23 19:41, Thiago Macieira wrote:
> On Monday, 14 August 2023 03:16:37 PDT Ivan Solovev via Development wrote:
>>> What I meant is that the product API of using the macros are the set of
>>> operators.
Hi,
> I see two fixes for this;
> - Keep the documentation API fix separate from the header file fix, and only
> merge it when Qt 6.9 got branched.
> This requires 'someone' to follow up on these things, though, more than a
> year after the deprecation decision has been made.
This approach
> I would therefore propose to remove the file from qt5.git:
+1 from my side.
I believe I simply do not have the clang-format tool installed on my system,
because it usually breaks the formatting of the patches, not improves them.
> One way to address these problems, especially for new devs or
+1
--
Ivan Solovev
Senior Software Engineer
The Qt Company GmbH
Erich-Thilo-Str. 10
12489 Berlin, Germany
ivan.solo...@qt.io
www.qt.io
Geschäftsführer: Mika Pälsi,
Juha Varelius, Jouni Lintunen
Sitz der Gesellschaft: Berlin,
Registergericht: Amtsgericht
gust 1, 2023 5:11 PM
To: development@qt-project.org
Subject: Re: [Development] C++20 comparisons @ Qt (was: Re: C++20 @ Qt)
On Tuesday, 1 August 2023 01:55:05 PDT Ivan Solovev via Development wrote:
> > BTW, this needs to integrate with QEqualityOperatorForType and
> > QLessThanOpe
was: Re: C++20 @ Qt)
On Monday, 31 July 2023 02:36:41 PDT Ivan Solovev via Development wrote:
>> Basically, what you suggest is that for every pair of comparable Qt
>> types we would need to double the amount of work that we do - provide
>> not only the helper functions for the macro
___
From: Thiago Macieira
Sent: Wednesday, July 26, 2023 5:18 PM
To: development@qt-project.org
Cc: Ivan Solovev
Subject: Re: [Development] C++20 comparisons @ Qt (was: Re: C++20 @ Qt)
On Wednesday, 26 July 2023 02:58:51 PDT Ivan Solovev via Development wrote:
> > That means it
relius, Jouni Lintunen
Sitz der Gesellschaft: Berlin,
Registergericht: Amtsgericht
Charlottenburg, HRB 144331 B
From: Thiago Macieira
Sent: Tuesday, July 25, 2023 4:42 PM
To: development@qt-project.org
Cc: Ivan Solovev
Subject: Re: [Development] C++20 comparisons
n,
Registergericht: Amtsgericht
Charlottenburg, HRB 144331 B
From: Thiago Macieira
Sent: Tuesday, July 25, 2023 2:11 AM
To: development@qt-project.org
Cc: Ivan Solovev
Subject: Re: [Development] C++20 comparisons @ Qt (was: Re: C++20 @ Qt)
On Monday, 24 July
Hi,
let me try to revive the discussion, because we want the C++20 comparison task
to be finished for Qt 6.7.
> > And we have the calling convention:
> > lhs.O(rhs);
> > Qt::O(lhs, rhs); // if you know the type
> >
> > using Qt::O;
> > O(lhs, rhs);
> > . // if you don't
>
Hi,
> Second, it's also easy to forget that since there's no receiver/context,
> the connection is always forced to be *direct*, which complicates things
> if multiple threads are involved.
I'm not a module maintainer, but I remember fixing a bug in Qt Bluetooth which
was caused by exactly this
> (*) That macro that does nothing until C++20 anyway, so I’d also add the
> support for the optional string-literal that C++20 also introduces..
Our tests actually show that this macro provides an expected warning on most of
the compilers that we use in the CI, even in C++17 mode.
IIRC, in my
Hi Jani,
> 3 exception requests so far:
> - C++20 comparison: exception request accepted
> - container-assign epic: exception request rejected
I think it's the other way around - the container-assign epic is accepted, and
the C++20 comparison is rejected.
Best regards,
Ivan
velopment@qt-project.org
Subject: Re: [Development] Requesting Feature Freeze Exception for C++20
comparison
On Friday, 2 June 2023 05:18:57 PDT Ivan Solovev via Development wrote:
> I'd like to request a Feature Freeze exception for the C++20 comparison
> task, due to the last-minute
Hi,
I'd like to request a Feature Freeze exception for the C++20 comparison task,
due to the last-minute discussions about the names of the helper functions to
be used. This is important because these helper functions are intended to be
exposed as public API.
The task is
Hi!
+1 to all suggestions
Best regards,
Ivan
From: Development on behalf of Marc Mutz
via Development
Sent: Tuesday, May 9, 2023 8:51 AM
To: qt-dev
Subject: [Development] Proposing changes to https://wiki.qt.io/Qt_Coding_Style
Hi,
I'd like to propose the
Hi,
+1 to the approach suggested by Kai.
Having comments would be very helpful, but I do not think that we need a
separate comment field for each entry.
Best regards,
Ivan
From: Development on behalf of Kai Köhne
via Development
Sent: Tuesday, February 14,
Hi,
Should the example updates be picked to 6.5, or is it only a 6.6 thing?
Is there any general guideline from the Release Team?
Best regards,
Ivan
From: Development on behalf of Kimmo
Leppälä via Development
Sent: Wednesday, January 18, 2023 10:51 AM
To:
Hi Jani,
I'm not sure that I understand your proposal.
Currently we have FF on the 9th of December, and the release in March. So, it's
roughly 3 months between FF and release.
Now you propose to shift FF to January (I assume, also around 10th ), and the
release to April. That gives the same 3
Hi Thiago,
> Now at https://codereview.qt-project.org/c/qt/qtbase/+/444222
Thanks for sharing it!
> In fact, I came up with a better solution yesterday after sending this email:
move the support to QUuid. This allows us to have the new (mostly) source-
compatible API in place and simply move
Hi Thiago,
> I was working on extended integers and added qint128 and quint128 to qglobal.h
(qtypes.h)
Can you provide a link to your WIP patch? I tried to search but couldn't find
it in gerrit.
> it's used in the API, with a constructor and a toUInt128(), but that's
all. It's also not
> 1. It doesn't, obviously. If you emit signals, any signal argument must
>be owning, or QueuedConnection cannot be used. Given that C++20
>requires us to mark up views and non-owning ranges (enable_view,
>enable_borrowed_range), I'm confident that we could detect attempts
>to
Hi Marc,
>> I would like to know how that is supposed to work in practice. We have a
>> lot of public API dealing with Qt containers all over. What are you
>> going to do to, for example, to
>>
>> void addActions(const QList );
>>
>> in qwidget.h? What should it look like when we're done and
41 matches
Mail list logo
