Hi,
I'm coming back to this thread, because this conclusion:
Confidential
On 18.03.24 16:28, Volker Hilsheimer wrote:
[...]
>
> to use those APIs you have to read the code. And
> then you’ll see that they are either undocumented, or documented as
> \internal.
>
> You can still use them, but you
I went though all of them (not the QML ones, for which I'm not
qualified) at least once.
Most have comments, I approved only 10. All maintainers, please check
whether your module has comments as soon as possible.
Another round of eyes wouldn't hurt, either.
Thanks,
Marc
Confidential
On 12.06.2
On 18.03.25 12:47, Giuseppe D'Angelo via Development wrote:
> On 18/03/2025 12:01, Marc Mutz via Development wrote:
>>> As I said, I'm skipping qtdeclarative and its dependencies. Not ideal
>>> but better than nothing. :(
>> Looks like it stopped working ag
On 04.02.25 16:25, Giuseppe D'Angelo via Development wrote:
> On 04/02/2025 14:16, Volker Hilsheimer wrote:
>>> Well, the tool itself is built just fine; it's binary identical to
>>> one built without Coverity. It's more likely that Coverity is doing
>>> something like tracing it during the build
On 17.03.25 20:09, Jøger Hansegård via Development wrote:
[...]
> I agree that it would be nice to have a compiler error but given that
> QStringList behaves the same way as std::vector, I am not sure it is a bug.
For the specific case of QList, we could take first and last by
reference, prevent
On 17.03.25 08:58, Volker Hilsheimer wrote:
>> On 14 Mar 2025, at 17:49, Marc Mutz via Development
>> wrote:
>>
>> Hi,
>>
>> TL;DR: do _not_ approve patches that do not "pick-to:" according to
>> QUIP-16 or explain in the commit message why the
On 17.03.25 08:10, Jörg Bornemann wrote:
> On 3/14/25 5:49 PM, Marc Mutz via Development wrote:
>
>> TL;DR: do _not_ approve patches that do not "pick-to:" according to
>> QUIP-16 or explain in the commit message why they deviate.
>
> This reads as if QUIP-16 wo
Hi,
TL;DR: do _not_ approve patches that do not "pick-to:" according to
QUIP-16 or explain in the commit message why they deviate.
Long version:
Just a reminder that QUIP-16¹ gives detailed instructions how far
certain sets of changes should be picked, so all maintainers / all
approvers shoul
Hi,
TL;DR:
- reminder that quadratic algorithms are rare, but easily introduced by
sloppiness
- request to change QUIP-16 to allow fixing quadratic behaviour in all
branches
Quadratic Bahaviour
O(N²) behaviour is very, very bad: doubling the input size quadruples
the run-time, a 10x increase
On 12.02.25 11:43, Cristian Le via Development wrote:
> I want to gather some feedback about adding a .gitreview file for all
> repos. The file would look like
>
> ```
> [gerrit]
> host=codereview.qt-project.org
> project=qt/qtbase
> defaultbranch=dev
> ```
I wouldn't mind, looks rather static,
two modules).
What say you?
Thanks,
Marc
On 07.03.24 10:02, Marc Mutz via Development wrote:
> Hi Tor Arne,
>
> On 06.03.24 09:34, Tor Arne Vestbø wrote:
>> The choice of where we use/allow `#pragma once` should not be coupled to
>> whether a header is considered publi
On 17.01.25 16:52, Allan Sandfeld Jensen wrote:
> Did anyone ever suggest or put pressure on the C++ standard committee to add
> strong unscoped enums?
Someone did:
// https://gcc.godbolt.org/z/69zWsoGP9
enum class Strong { One, Two, Three };
#ifdef __cpp_using_enum
using enum Strong;
On 16.01.25 15:05, Thiago Macieira wrote:
> On Thursday 16 January 2025 04:55:56 Pacific Standard Time Marc Mutz via
> Development wrote:
>> https://gcc.godbolt.org/z/6exEonP5o, maybe?
>
> Yes.
@Ville, @Peppe: do you happen to know whether this is supposed to work
(using
On 05.05.23 08:10, Thiago Macieira wrote:
> On Thursday, 4 May 2023 22:48:44 PDT Thiago Macieira wrote:
>> On Thursday, 4 May 2023 22:28:44 PDT Thiago Macieira wrote:
>>> But for those that use a very name, the API becomes cumbersome:
>>>Qt::Alignment al = Qt::AlignmentFlag::Left;
>>>
>>> Can w
Hi Tor Arne,
On 16.01.25 12:31, Tor Arne Vestbø wrote:
>
>> On Jan 16, 2025, at 11:56, Marc Mutz via Development
>> wrote:
>>
>> Like every API review, so also in 6.9, we have the discussions between
>> proponents of scoped vs. unscoped enums in class scope.
Sorry for the double post; I blame Outlook's UI, and so should you ;)
On 16.01.25 11:58, Marc Mutz via Development wrote:
> Hi,
>
> Groundhog Day...
>
> Like every API review, so also in 6.9, we have the discussions between
> proponents of scoped vs. unscoped enums in c
Hi,
Groundhog Day...
Like every API review, so also in 6.9, we have the discussions between
proponents of scoped vs. unscoped enums in class scope.
Can we, please, settle this by strengthening the wording of
https://wiki.qt.io/API_Design_Principles#Enums_in_classes to something
that requires
e extremely-fine-grained QT_NO_ opt-outs gracefully. But I
guess it wouldn't be _that_ hard to make the deprecation macros
per-module, if that would help people?
Thanks,
Marc
On 14.01.25 22:15, Marc Mutz via Development wrote:
> On 14.01.25 14:50, Volker Hilsheimer wrote:
>&g
On 14.01.25 14:50, Volker Hilsheimer wrote:
> None of this implies that “Qt 7 will be source compatible with Qt 6”, or
> results in the automatism that Qt5Compat (or QtCharts, DataViz3D)
> continue to be included and maintained in Qt 7. Some things will stay,
> some won’t. We now have more ways t
Hi.
At QtCS last year, we had a session on deprecations. From the summary at
https://wiki.qt.io/QtCS2024_Deprecate, we've done (2)¹, but it seems
like we have not come to grips with what (1) (deprecation is not
removal) actually means.
As far as I am concerned, it cannot mean "continue as befo
Hi,
1/
I today refused to perform a re-licensing of a .cpp file being renamed
to .qdoc.¹ QUIP-18² has no provisions for files transitioning between
what QUIP-18 calls file "classifications"³, even if they have different
required license specifiers.
Can someone please clarify the process here?
On 25.11.24 09:38, Arno Rehn wrote:
> Hi Marc,
>
> Am 25.11.2024 um 09:34 schrieb Marc Mutz via Development:
>> https://contribute.qt-project.org/quips/5 says
>>
>> > Status: Superseded
>>
>> What supersedes it, please? Should it not say "Sup
Hi,
https://contribute.qt-project.org/quips/5 says
> Status: Superseded
What supersedes it, please? Should it not say "Superseded by _link_"?
Thanks,
Marc
--
Marc Mutz (he/his)
Principal Software Engineer
The Qt Company
Erich-Thilo-Str. 10 12489
Berlin, Germany
www.qt.io
Geschäftsfüh
On 20.09.24 11:51, Ville Voutilainen wrote:
> On Thu, 19 Sept 2024 at 17:35, Volker Hilsheimer via Development
> wrote:
>> My preference would be "static constexpr inline”, as static is the most
>> important piece of information (storage and calling convention in case of
>> member functions), co
On 18.09.24 17:18, Thiago Macieira wrote:
> Which one are we?
>
> That is,
>constexpr inline foobar
> or
>inline constexpr foobar
>
> I prefer the former. And then there's the question of the ordering when static
> is present too.
Since they are identical, from a C++ pov, the order is no
Hi,
I don't see how
On 06.09.24 22:34, Thiago Macieira wrote:
[...]
> In turn this means there's no support for throw-on-violations for Qt code in
> production.
[...]
necessarily follows, at least as long as we speak about a Qt-proprietary
mechanism.
Another thing I neglected to mention is tha
Nothing that you describe in the context of a bug in our code here is
specific to throwing precondition checkers. If you weren't checking with
active precondition handlers (the status quo in release mode atm), then
you'd likely would have run into language UB on precondition violation,
with equ
Hi,
Over lunch at QtCS, Thiago and I have reached common ground on this.
Seeding the proposal:
We continue to follow the Lakos Rule, but if slapping noexcept on a
narrow-contract function demonstrably improves "things" (performance,
code size?) significantly, then you MAY slap a noexcept on th
Hi,
TL;DR: Never export non-polymorphic classes at class-level and always
define destructors of polymorphic classes, and define them out-of-line.
The class-level export macro used to be a trigger for syncqt to generate
a forwarding QClass header, so every public class had them in the past,
an
On 31.08.24 20:01, Ville Voutilainen wrote:
> On Fri, 30 Aug 2024 at 19:21, Thiago Macieira
> wrote:
>> For the non-simple cases, we may need two macros, one that expands to:
>>
>>noexcept(noexcept(std::string_view{"", 1}))
>>
>> and the other that expands to the pre() specifier.
>
> Right.
On 29.08.24 17:31, Thiago Macieira wrote:
> What I'd like to change is:
> - for inline code, where the function's noexceptness is likely to be used in
> a
> noexcept expression elsewhere and that causes slower code to be used
How does that square with being tool-checkable? That sounds like a
I'm ok with 1-3, I'm not ok with 4.
The state of the art is what the std prescribes, not what a stdlib
implementation does. stdlibs are magic; they can theoretically remove
the noexcept for new code and keep it for old. Or they can let contract
violations pass magically. We can't, at least not w
On 26.08.24 22:12, Thiago Macieira wrote:
> On Monday 26 August 2024 12:55:04 GMT-7 Marc Mutz via Development wrote:
>> I don't see a proposal for an alternative rule in the above. Please
>> provide a) a new rule and b) rationale for it. Bonus points for being
>> impleme
Your two examples are quite different, though:
On 26.08.24 22:28, Thiago Macieira wrote:
> On Monday 26 August 2024 12:59:54 GMT-7 Marc Mutz via Development wrote:
>> Part of why I'm sympathetic to the assertions throw mantra is that I
>> used it very successfully in Kleopat
On 27.08.24 01:33, Ville Voutilainen wrote:
> On Mon, 26 Aug 2024 at 20:41, Marc Mutz via Development
> wrote:
>> What is unacceptable in (1) (doing nothing) is not even _informing_
>> users about what we found¹, so _they_ can decide for themselves what to do.
>>
>>
On 26.08.24 21:49, Thiago Macieira wrote:
> In particular, I don't see why (b) should be used at all. A precondition
> violation implies that the state was unexpected at that point. How is an
> exception going to help recovering? That sounds like an exception that would
> bubble up all the way back
On 26.08.24 19:56, Thiago Macieira wrote:
> The Lakos Rule says that methods that only methods with wide contracts should
> be noexcept. That is, if your method has a precondition, it should not be
> noexcept.
>
> This is apparently predicated on the fact that the preconditions will be
> implement
On 26.08.24 08:43, Ville Voutilainen wrote:
>> IMHO, (1) is not an acceptable option. Us C++ professionals having identified
>> this problem after years of it lying dormant, it behooves us, at the
>> very least, to educate our users about this, e.g. by adding docs, and
>> maybe a qWarning() in ~QVa
On 26.08.24 11:08, Giuseppe D'Angelo via Development wrote:
> Il 26/08/24 07:24, Marc Mutz via Development ha scritto:
>> IMHO, (1) is not an acceptable option. Us C++ professionals having
>> identified
>> this problem after years of it lying dormant, it behooves us
On 09.12.23 18:38, Thiago Macieira wrote:
> On Friday, 8 December 2023 18:51:19 PST Marc Mutz via Development wrote:
>> I think we need to mandate that if you want qint128 support, then you
>> must compile with gnu++NN, which is actually the default on both GCC and
>> Clang. W
Hi,
During my vacation, the last bits of my qsnprintf() work have merged.
The user-visible changes are:
- qsnprinf() has gained the __attribute__((format(printf))) it has been
lacking since its inception, so -Wformat now works (and has caught
some problems in Qt). The attribute has been pi
(sorry for the late entrance, was OOO the last two weeks)
My vote goes to (3). (2) is a good intermediate step (e.g. for Qt 6,
with Qt 7 converting to static_assert()). Remember that ctors are
implicitly noexcept in C++, so you need to do actual work to make a type
that's not nothrow_destructib
We should really try to fix this before 6.8.0 (LTS).
On 09.12.23 18:38, Thiago Macieira wrote:
> On Friday, 8 December 2023 18:51:19 PST Marc Mutz via Development wrote:
>> I think we need to mandate that if you want qint128 support, then you
>> must compile with gnu++NN, which
On 12.06.24 20:21, Thiago Macieira wrote:
> On Tuesday 11 June 2024 12:44:11 GMT-7 Marc Mutz via Development wrote:
[...]
>> I don't want to break _any_ code. I could live with QAnyStringView(char)
>> being deprecated before a future QT_NO_CAST_FROM_CHAR becomes the
>>
On 11.06.24 21:08, Giuseppe D'Angelo via Development wrote:
> Il 11/06/24 07:12, Thiago Macieira ha scritto:
[...]
> > I'd like to know how much breakage this solution or mine would imply.
I may have missed something, but I still can't see what your solution
is? I've enumerated the options, would
On 10.06.24 23:13, Thiago Macieira wrote:
> On Monday 10 June 2024 05:39:26 GMT-7 Marc Mutz via Development wrote:
>> Since there are four bugs³ in QString::arg() that are all fixed by the
>> existing patch chain porting the whole thing to QAnyStringView, and
>> since the m
Hi,
TL;DR:
- QASV(char) is UTF-8, but QChar(char) is L1
- propose to fix QASV, not QChar
- iow: char literals remain L1, not become UTF-8
- but char[] remains UTF-8
- propose to deprecate char and char[] literals for u8 and _L1 in Qt 7
(= make QT_NO_CAST_FROM_ASCII the default)
While
Because I'm seeing all the same issues over and over again, I've created
https://wiki.qt.io/Things_To_Look_Out_For_In_Reviews during the last API
Review. I communicated as much in the 6.7 API review thread.
Now it's time to make use of the wiki page:
All maintainers, please confirm that the upl
On 07.05.24 18:46, Volker Hilsheimer wrote:
> In the long run, a mechanism in Qt Core makes sense, IMHO. That “it’s a
> browser” is not true for every possible call of the QDesktopServices API.
We need something _now_ for QtNetworkAuth, though. What do these options mean
for OAuth support in QtN
On 07.05.24 16:30, Thiago Macieira wrote:
> On Monday 6 May 2024 23:08:07 GMT-7 Marc Mutz via Development wrote:
[...]
>> I'm currently fighting an older version of openfortifyvpn (CLI on Linux)
>> which cannot, yet, spin up the browser. Newer versions are reported to
>>
On 07.05.24 14:58, Tor Arne Vestbø wrote:
[...]
>> Honestly, I don't understand the push-back for the move. It seems only
>> logical to me: QUrl is in QtCore, so IMHO, it's only logical to have
>> QUrl _handlers_ in QtCore, too. And in other emails, I showed use-cases
>> of CLI programs that need o
On 06.05.24 13:08, Tor Arne Vestbø via Development wrote:
>
>
>> On 6 May 2024, at 13:06, Juha Vuolle wrote:
>>
>>> QtNetworkauth leaves the QDesktopServices::openUrl() usage/non-usage
>>> at the user's discretion, and thus that currently won't force a Gui
>>> dependency.
>>
>> (Ah shoot. Correc
On 06.05.24 17:18, Thiago Macieira wrote:
> On Monday 6 May 2024 00:02:58 GMT-7 Marc Mutz via Development wrote:
>> Juha is currently improving the OAuth implementation in QtNetworkAuth.
>> The protocol involves launching the system browser to get an access
>> code, in tu
Hi,
Juha is currently improving the OAuth implementation in QtNetworkAuth.
The protocol involves launching the system browser to get an access
code, in turn used to get access tokens with which services can then be
accessed.
OAuth therefore requires a UI to run the browser in, but not necessar
On 23.04.24 16:27, Volker Hilsheimer wrote:
> Jannis is already approver, so he already has all the privileges as far as
> source code access is concerned. If we want to start doing background checks
> (and that’s a worthwhile discussion to have), we’d have to do so when
> nominating approvers,
Hi Frank,
On 23.04.24 13:16, Frank Meerkötter wrote:
> I am going to step down as the maintainer of Qt OPC UA. I have not been
> very active recently.
Thanks for your work on QtOpcUa over the years!
> I would like to nominate Jannis Völker as
> the new maintainer.
>
> https://codereview.qt-p
On 16.03.24 01:47, Konstantin Shegunov wrote:
> On Fri, Mar 15, 2024 at 10:48 PM Marc Mutz via Development
> mailto:development@qt-project.org>> wrote:
>
> The member variable thing sounds very wrong. I'd be surprised if it
>
On 15.03.24 21:21, Jaroslaw Kobus via Development wrote:
[...]
> Just found some reasoning, though not sure how much valid it is:
> https://www.learncpp.com/cpp-tutorial/hiding-inherited-functionality/
>
> Probably there are more resources about this topic in the internet.
That page doesn't look
On 15.03.24 18:31, Christian Kandeler via Development wrote:
> On 3/15/24 18:09, Marc Mutz via Development wrote:
>> I like simple rules. "Overrides should have the same access level as the
>> initial virtual function." is a simple rule.
>
> But it makes no sense in
On 15.03.24 14:28, Volker Hilsheimer via Development wrote:
>> On 15 Mar 2024, at 12:30, Marc Mutz via Development
>> wrote:
>> On 15.03.24 09:11, apoenitz wrote:
>>> On Fri, Mar 15, 2024 at 07:16:59AM +, Marc Mutz via Development wrote:
>> [...]
>>
On 15.03.24 09:11, apoenitz wrote:
> On Fri, Mar 15, 2024 at 07:16:59AM +0000, Marc Mutz via Development wrote:
[...]
>> Please note that this means that any override (and all new QObject
>> classes should contain one, since, in case we ever need it, it might not
>> be possibl
08:58, Marc Mutz via Development wrote:
> Hi,
>
> In API review, we detected some overrides that changed the access
> specifier vis-a-vis the original virtual function
> (https://wiki.qt.io/Things_To_Look_Out_For_In_Reviews#Polymorphic_Classes
> Item 5.3).
>
> One
Hi,
In API review, we detected some overrides that changed the access
specifier vis-a-vis the original virtual function
(https://wiki.qt.io/Things_To_Look_Out_For_In_Reviews#Polymorphic_Classes
Item 5.3).
One of them was a protected reimplementation of QObject::event() (which
itself is public
ote:
>> On 4 Mar 2024, at 10:57, Marc Mutz via Development
>> wrote:
>>
>> Hi,
>>
>> TL;DR:
>> - Treat all APIs not clearly marked as private (private access, *Private
>>namespace or "We mean it!" comment) as public, in particular keep
. The new thing is that installed
headers cannot use #pragma once, and that's enforced by tooling, so
can't be forgotten. Adding a comment to such headers is something
additional that authors and reviewers need to keep in mind.
I'd prefer the path of least resistance here.
Thanks
We have agreed that for some headers we allow use of #pragma, but taking
> myself as a reference, I doubt that it’s obvious to everyone which
> headers are installed, and when it’s allowed to use #pragma, and when
> it’s mandatory to use #pragma. Perhaps adding the “We mean it” comment
Hi,
TL;DR:
- Treat all APIs not clearly marked as private (private access, *Private
namespace or "We mean it!" comment) as public, in particular keep SC/BC
and deprecate before remove.
- Avoid adding APIs that aren't clearly private or public in the future.
I'd like to start a discussion ar
Hi,
DL;DR: Use #pragma once in all non-installed headers
The question recently came up "what is a private header". And the answer
isn't just "_p.h, of course". We have tons of headers that are "private"
without being marked as such with _p.h and "We mean it." comment.
The first realization is
On 05.02.24 23:42, Thiago Macieira wrote:
> On Monday, 5 February 2024 01:36:39 PST Marc Mutz via Development wrote:
>> I've always understood it such that we as Qt must preserve the property
>> that the hash for equal elements is equal within _one_ run of _one_
>> proce
On 05.02.24 19:07, apoenitz wrote:
> On Mon, Feb 05, 2024 at 09:36:39AM +0000, Marc Mutz via Development wrote:
>> Hi,
>>
>> I've always understood it such that we as Qt must preserve the property
>> that the hash for equal elements is equal within _one_ run of _
On 03.02.24 18:13, Thiago Macieira wrote:
> On Wednesday, 21 December 2022 09:51:52 PST Vladimir Minenko via Development
> wrote:
>> We got four user stories on Qt Bug Reports:
>>
>> 1. Use C++20 code with Qt - https://bugreports.qt.io/browse/QTBUG-109360
>> 2. C++20 is required for the development
I think we don't drop supported compilers, except in LTS+1 releases (6.9
being the next).
On 03.02.24 18:08, Thiago Macieira wrote:
> The compiler is pretty buggy and has several, unfixed conformance issues with
> C++.
>
> One year ago I asked on the interest mailing list about using a non-lates
Hi,
I've always understood it such that we as Qt must preserve the property
that the hash for equal elements is equal within _one_ run of _one_
process. This means you can use the hash in I/O in any way. That's why
we have qt_hash, which you _can_ (and do) use in I/O (but is private
API, AFAIK
https://wiki.qt.io/Things_To_Look_Out_For_In_Reviews#Specifically_QT_%2A_REMOVED_SINCE_%2F_QT_%2A_INLINE_SINCE
--
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 Gesells
05.01.24 09:28, Marc Mutz via Development wrote:
> Hi,
>
> In the hope of spreading knowledge, I've created a staging area in the
> wiki called "Things to look out for in reviews." This is a
> low-entry-barrier way to quickly publish a guideline. After each
> release
Thanks! Added to
https://wiki.qt.io/Things_To_Look_Out_For_In_Reviews#Variables
On 18.01.24 04:35, Thiago Macieira wrote:
> See http://bugreports.qt.io/browse/QTBUG-121135 for the issue and
> https://codereview.qt-project.org/c/qt/qtbase/+/531251 for the solution.
>
> TL;DR: if you define a stat
Hi,
In the hope of spreading knowledge, I've created a staging area in the
wiki called "Things to look out for in reviews." This is a
low-entry-barrier way to quickly publish a guideline. After each
release, we should discuss where to move these "things" to, see the page
for details:
https://
On 16.12.23 10:20, apoenitz wrote:
> Recently there were two serious regression on the Qt side due to "just using
> string views" (which would also be formally permitted), and I've seen now a
> patch that changes a map to a hash to avoid part of the porting "work" to the
> new comparison scheme tha
On 13.12.23 18:36, Thiago Macieira wrote:
> So, +1 for me on going ahead.
Thanks!
Is anyone else here for/against?
--
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 G
On 13.12.23 12:46, Marc Mutz via Development wrote:
> The counter-argument is that this doesn't change much because the C++
> standard knows an operation called
Was interrupted when writing this, then forgot to end the sentence
before sending :) Sorry...
...
https://eel.
Hi,
TL;DR: is the conversion of a class to the new comparison helper a
"feature"?
So, the framework, incl. the necessary qdoc command and some ports of
classes (QDate/Time) have made it into 6.7 last week, but the current
state of the code excludes some helper functions necessary for product
Hi,
After spending countless hours between Ivan and myself fighting GCC's
mysteriously-vanishing support for __int128_t (= qint128),
it turns out that with -ansi/-std=c++NN, not even the most basic of
work: std::is_signed_v is _false_! I repeat: _FALSE_.
The following is /my/ professional op
Hi,
I've developed these to deprecate qspan_p.h in favour of qspan.h, but
we'll now just remove the old header instead. I can see us apply it to
qglobal.h, but not for 6.7.
But if you have a use for a cross-platform #warning or the deprecation
of a whole header, restore and stage
https://code
On 05.12.23 10:06, Giuseppe D'Angelo via Development wrote:
> Il 05/12/23 03:52, Kevin Kofler via Development ha scritto:
>> Marc Mutz via Development wrote:
>>> Until then, either you want to be notified of sub-optimal APIs asap,
>> What is "suboptimal" abou
On 04.12.23 09:06, Jyrki Yli-Nokari wrote:
>
> While I do not use them, I feel that deprecating such core functionality of a
> framework without measurable gain would seriously harm anyone using them and,
> most importantly, fundamentally harm the promise and dependability of Qt as a
> framework
I feel we're turning in circles here, so let me give a rundown of what I
thought we might meet at:
- Introduce Qt::{partial,weak,strong}_ordering
- BC and SC-as-much-as-possible to std::*_ordering
- Qt 7: Qt::foo_ordering becomes a typedef for std::foo_ordering,
like QPair in Qt 6
- QParti
On 14.11.23 11:54, Edward Welbourne wrote:
> Volker Hilsheimer (14 November 2023 10:00) wrote:
>> Adding Qt::snake_case interims that are BC with std, with conversion
>> from/to QPartialOrdering, is the right thing to do.
>
> Perhaps namespace q20 would be a better place for them, given both the
>
On 14.11.23 09:31, Marc Mutz via Development wrote:
[...]
> And then naming them Qt::partial_ordering is just consequent, because
> users can reach ultimate SC by doing something like
>
> #ifdef __cpp_lib_three_way_comparison
> using std::partial_ordering;
>
On 13.11.23 19:24, Thiago Macieira wrote:
[...]
> It could be done, but I just don't see the value.
I do.
> If we do it, please come up with proper Qt-style class names for it. No
> snake_case.
No. We don't _want_ these to be Qt-style classes. _You_ should not want
them to be Qt-style classes.
On 13.11.23 19:25, Thiago Macieira wrote:
> 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
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 sol
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?
Which leaves us with:
- MSVC doesn't export anything by default; inline functions are,
however, exported when the surrounding class is wholly ex
On 08.11.23 16:46, Thiago Macieira wrote:
> On Wednesday, 8 November 2023 00:38:32 PST Marc Mutz via Development wrote:
>> Let's not mix up topics here...
>>
>> 1/ We're not responsible for the ABI of third-party libraries. As long as
>> we document that the
+1
Disclaimer: Tatiana is in the same team as myself; Alexey is a colleague
at TQtC.
On 06.11.23 15:55, Alex Blasche via Development wrote:
> Hi,
>
> Qt GRPC and Qt Protobuf were added to Qt a while ago. However until now they
> have been in Tech Preview mode. As we investigate the remaining i
+1
Disclaimer: we're in the same team at TQtC...
On 08.11.23 10:00, Paul Wicking via Development wrote:
> Hi everyone,
>
> I would like to nominate Jaishree Vyas for approver rights in the Qt
> project.
>
> Jai has joined TQtC as a Documentation Engineer back in February 2022.
> Since then, s
I agree that the latter is a problem; I stated as much in my previous
email, and gave (1) and (3) as solutions.
But I still don't see how the former is a problem, or, if it is, why (3)
(BC between {std,Qt}::_ordering) doesn't fix it, too.
On 08.11.23 01:16, Thiago Macieira wrote:
> O
On 07.11.23 20:12, Thiago Macieira wrote:
> On Tuesday, 7 November 2023 06:28:51 PST Ivan Solovev via Development wrote:
[...]
>> The main reason to use `auto` is that it will allow us to avoid unnecessary
>> `std::*_ordering -> Q*Ordering -> std::*_ordering` conversions in the C++20
>> case, which
On 07.11.23 15:28, Ivan Solovev via Development wrote:
>
> So, my question is - shoud we support mixing C++17 and C++20 in one binary?
To be clear: This is not about Qt compiled with C++17 used in projects
compiled with C++20. This is about one .cpp file being compiled with
C++17 and another .c
On 21.09.23 18:02, Thiago Macieira wrote:
> On Thursday, 21 September 2023 02:10:22 PDT Ivan Solovev via Development
> wrote:
>> But I'd say that if someone wants to implement three-way comparison for
>> their classes in C++17, then a bit better understanding of the language
>> features is a reason
On 20.09.23 21:09, Marc Mutz via Development wrote:
> Will un-deprecate and pour some TLC over it.
→ Chain ending in https://codereview.qt-project.org/c/qt/qtbase/+/505691
--
Marc Mutz
Principal Software Engineer
The Qt Company
Erich-Thilo-Str. 10 12489
Berlin, Germany
www.qt
1 - 100 of 214 matches
Mail list logo
