owed alongside all others, or none are. It can't be that
we apply double standards.
Thanks,
Marc
--
Marc Mutz (he/his)
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
_review_6.10+status:open>
>
> Please review the diffs as soon as possible.
>
> br,
>
> Jani
>
>
--
Marc Mutz (he/his)
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 Lintun
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
At least I got a few reports from Coverity Scan in the last days.
>
> As I said, I'm skipping qtdeclarative and its dependencies. Not ideal
> but better than nothing. :(
Looks like it stopped working again? The last scan is from eight days ago?
--
Marc Mutz (he/his)
Principal Softwa
d overloading. Prefer named constructors
(QList::fromRange), and explicit function names
(appendString()/appendByteArray() instead of
append(QString)/append(QByteArray)). Make ctors and conversion operator
explicit.
Thanks,
Marc
--
Marc Mutz (he/his)
Principal Software Engineer
The Qt Co
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
UIP-16 to allow more refactorings:
https://codereview.qt-project.org/c/meta/quips/+/608523
Thanks,
Marc
--
Marc Mutz (he/his)
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
ips/+/627689
See
https://codereview.qt-project.org/q/owner:marc.m...@qt.io+message:quadratic
for example fixes.
Thanks,
Marc
--
Marc Mutz (he/his)
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 Lintu
rg/opendev/git-review/latest/installation.html#gitreview-file-format
> [2]: https://bugreports.qt.io/browse/QTBUG-132604
>
>
--
Marc Mutz (he/his)
Principal Software Engineer
The Qt Company
Erich-Thilo-Str. 10 12489
Berlin, Germany
www.qt.io
Geschäftsführer: Mika Pälsi, Juha Vare
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
Strong;
#else
inline constexpr auto One = Strong::One;
inline constexpr auto Two = Strong::Two;
inline constexpr auto Three = Strong::Three;
#endif
use(One); use(Two); use(Three);
The ice for unscoped enums becomes _very_ thin.
--
Marc Mutz (he/his)
Principal Software En
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
don't know why:
> https://gcc.godbolt.org/z/6jf7Ebecq
>
> Looks like the using enum feature is not very useful for us. Back to the
> drawing board for scoped flags
https://gcc.godbolt.org/z/6exEonP5o, maybe?
--
Marc Mutz (he/his)
Principal Software Engineer
The Qt Company
Eric
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
(https://doc.qt.io/qt-6/qgrpcstatus.html) elegantly evades the issue by
putting the enum at namespace scope.
Thanks,
Marc
--
Marc Mutz (he/his)
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 Lint
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
at their own
pace, in their own order, without being hit by these walls of changes
with every Qt version. Something we ourselves have recently gotten a
dose of when we tried to bump the QT_VERSION to 0x061000...
-- Do unto others as you would have done to you.
Th
arc
¹ https://codereview.qt-project.org/c/qt/qtbase/+/599356
² Not in the REMOVED_SINCE sense, as that just removes deprecated
API/ABI at _user_ discretion, but in the QT_VERSION < 7 or actually,
physically, delete the code.
--
Marc Mutz (he/his)
Principal Software Engineer
The Qt C
https://contribute.qt-project.org/quips/18
³ https://contribute.qt-project.org/quips/18#classification-of-files
Thanks,
Marc
--
Marc Mutz (he/his)
Principal Software Engineer
The Qt Company
Erich-Thilo-Str. 10 12489
Berlin, Germany
www.qt.io
Geschäftsführer: Mika Pälsi, Juha Vare
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, Germ
t just for the three keywords in question, please
(and allow exceptions for late additions)?
FTR, I'm voting -1 on "static constexpr inline" (without further
qualification), because Q_CONSTINIT must come _first_ (it's an attribute
in C++17, keyword only in C++20), and it ma
hether inline or constexpr comes first has none, IMNSHO.
HTH,
Marc
¹ https://www.oreilly.com/library/view/c-coding-standards/0321113586/
Item 0: "Don’t sweat the small stuff. (Or: Know what not to standardize.)"
--
Marc Mutz (he/his)
Principal Software Engineer
The Qt Company
Erich-Thi
overloaded on nexcept/non-noexcept for a binary-compatible
switch between the different build modes (e.g. by
template
R func() noexcept(!Throw);
Or using a mechanism similar to REMOVED_SINCE (which is also a way to
remove noexcept that we have incorrectly added)).
Thanks,
Marc
-
then may be saved to disk, making it permanent and the data error not
> getting caught.
>
>>> My argument is "first, do no harm" (or "don't make it worse"). Exceptions
>>> should only be used if there's a proper correction code for it.
>>
t implementation rather than on Qt code. The *pre* condition
> indicates something that must be true before the method is called and
> therefore the method's own noexcept specification does not apply *yet*.
>
>
--
Marc Mutz (he/his)
Principal Software Engineer
The Qt Comp
just don't know what else will
crop up, until it does.
So I maintain that the TL;DR: is the soundest engineering practice for
exporting classes, and should be followed - without exception.
Thanks,
Marc
PS: if you wonder about the second part of the rule, that's
https://wiki.qt.io/T
. Besides, libc++
recently ditched their build-conditional noexcept approach, AFAIK. We
needn't make mistakes others have already done for us.
Thanks,
Marc
--
Marc Mutz (he/his)
Principal Software Engineer
The Qt Company
Erich-Thilo-Str. 10 12489
Berlin, Germany
www.qt.io
Geschäftsf
.qt-project.org/c/qt/qtbase/+/193707 *cough*
--
Marc Mutz (he/his)
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,
ate-of-the-art, namely the Standard
> Libraries, where they have marked noexcept functions with certain
> preconditions like std::vector::operator[] and std::basic_string_view char+len
> constructor.
>
> IF and when they deploy a solution to allow turning those checks
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.
>>
>>
he exception's what() and report back over the UI server channel
that an assertion happened and the client would show a message box with
the assertion details, copyable from a QMessageBox into a bugreport.
T'was a boon for testing.
--
Marc Mutz (he/his)
Principal Software Engineer
it can be
fixed in the next major release (removing noexcept is BiC). So not only
do we have _no_ incentive to diverge from std, we also have a rather
large incentive to keep doing what std is doing.
Thanks,
Marc
--
Marc Mutz (he/his)
Principal Software Engineer
The Qt Company
Erich-Thilo-
e found¹, so _they_ can decide for themselves what to do.
¹ neither at compile-time, nor runtime, nor coding time (static checker)
nor at documentation reading time.
We want our APIs to be easy to use and hard to abuse. It's easy to abuse
QVariant in this way, so it behooves us to try t
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
tring::arg().
If you depend on the particular Windows return values, you'll need to
fix that, too.
The rest should be ok with s/q(v?)snprintf/std::\1snprintf/g;
Thanks,
Marc
--
Marc Mutz (he/his)
Principal Software Engineer
The Qt Company
Erich-Thilo-Str. 10 12489
Berlin, Germany
www.qt.io
Ge
onally noexept, like QCache::take, even though that can never be
> the case given the static_assert.
> [2] At least in cases where we can detect it at compile time; the API
> using QMetaType would require storing the necessary information in
> QMetaType, and a runtime check.
&g
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
>>
ed about. I'm pretty sure that
we can adapt the existing Clazy check for QString(const char*) to
suggest _L1 or u8, depending on content, instead. But figuring out
whether a QByteArray constructed from char[] is meant to be binary or
UTF-8 (or L1, for that matter) is nothing a tool can d
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
...]
³ to wit:
- https://bugreports.qt.io/browse/QTBUG-126053 (char8_t)
- https://bugreports.qt.io/browse/QTBUG-126054 (wchar_t)
- https://bugreports.qt.io/browse/QTBUG-126055 (qfloat16)
- https://bugreports.qt.io/browse/QTBUG-125588 (char16_t)
- and the issue at hand:
https://bugreports.qt.io/browse/Q
<https://codereview.qt-project.org/q/topic:qml_api_review_6.8>
>
> Please review the diffs as soon as possible.
>
> br,
>
> Jani
>
>
--
Marc Mutz (he/his)
Principal Software Engineer
The Qt Company
Erich-Thilo-Str. 10 12489
Berlin, Germany
www.qt.io
paying y’all’s salary, then I’d strongly suggest to go with option
> 1, and maybe follow up with Option 2 for 6.9, while we take the time it takes
> to figure out how to properly wrap intents etc into a cross-platform
> abstraction.
I don't see (1) solving anything for QtNetworkAu
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
>>
etworkAuth will
have to be ported, QtCore move or not, public API or not.
Thanks,
Marc
--
Marc Mutz (he/his)
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,
he code (if we can provide it as private API, there can't be many).
So, if this boils down to private vs. public API: Why keep it private?
It's not new API, it's just renamed for BC reasons.
Thanks,
Marc
--
Marc Mutz (he/his)
Principal Software Engineer
The Qt Company
Erich-Thilo-S
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
m handlers? We have XDG-code in QtCore already (mime types),
so we should have all the information in Core already to implement the
functionality, should we not?
Thanks,
Marc
--
Marc Mutz (he/his)
Principal Software Engineer
The Qt Company
Erich-Thilo-Str. 10 12489
Berlin, Germany
o to some degree represents
the project to the public, too.
And yes, the borders are grey zones here.
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
Si
C UA).
+1
Jannis seems to be on top of the module, AFAICT.
BUT: I've never met Jannis in person, so maybe Eva or other C-suite people from
basyskom can confirm that this isn't going to be an xzlib-like situation? E.g.
there's no Jannis on https://www.basyskom.de/ueber-uns/ :)
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
>
codify a lot more
stuff than we have done in the past (and, where possible, have tools
check it). Look at all the google-specific checks in clang-tidy for example.
Thanks,
Marc
--
Marc Mutz
Principal Software Engineer
The Qt Company
Erich-Thilo-Str. 10 12489
Berlin, Germany
www.qt.io
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
become protected, please speak up before we fork Qt 7.0 :)
Thanks,
Marc
¹
https://codereview.qt-project.org/c/qt/qtdeclarative/+/528290/comment/f51938ca_fd065a18/
--
Marc Mutz
Principal Software Engineer
The Qt Company
Erich-Thilo-Str. 10 12489
Berlin, Germany
www.qt.io
Geschäftsführer: Mika
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
ame time, we should make sure that we don't accept such
semi-public APIs going forward anymore.
In most cases, this isn't really any extra work for us, but it will help
both current users of such APIs (they get a warning with suggested
replacements instead of an out-of-the-blue linker erro
> have time to do that for a while (perhaps ditto for
> https://wiki.qt.io/Qt_Coding_Style), but perhaps someone else wants to give
> this a shot.
>
> ___
> Development mailing list
> Development@qt-project.org
> https://lists.qt-
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 _
ause it
means we'll need to maintain C++17-compatibility in the vast majority of
the code-base.
I have some sympathy for (b), and I could live with the required
#ifsef'ery for the time being, because it would be something that's
required for (public) headers only.
Jani, Vladim
ort an X-1 version of MSVC for as long as practicable, a minimum of
> a few years. Well, in April this year, MSVC 2019 will be 5 years old, though
> fortunately it's still getting updates. Considering MSVC 2022 will be 3.5 at
> that time, I think it's time to drop.
>
>
--
r))
>
> but it would be far more useful to have
>
> qHash(QLatin1StringView(str)) == qHash(QString(str))
>
> I've made the change for the non-zero seeds, but one couldn't rely on the
> above unless it applied for every seed.f
>
>
--
Marc Mutz
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
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
it calls
> std::vector_M_realloc_insert(), which takes the integer by reference, so
> the compiler emits an import from the DLL.
>
> This appears to be a GCC bug/shortcoming. Clang and MSVC apparently
> automatically emit and export the variable for you:
> https://mingw.godb
> * https://codereview.qt-project.org/q/topic:api-change-review-6.7
> <https://codereview.qt-project.org/q/topic:api-change-review-6.7>
> * https://codereview.qt-project.org/q/topic:qml_api_review_6.7
> <https://codereview.qt-project.org/q/topic:qml_api_review_6.7>
ot; to the
> new comparison scheme that makes that change not quite "mechanical".
Sorry, I am not aware of either, and the lack of specificity in the
above makes it impossible to respond in a meaningful way, so I won't try to.
Thanks,
Marc
--
Marc Mutz
Principal Software Engin
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
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.
nd the already-up-for-review
QModelIndex/QPersistentModelIndex.
Without this, it's hard to prove out the framework actually works in all
cases.
Thanks,
Marc
--
Marc Mutz
Principal Software Engineer
The Qt Company
Erich-Thilo-Str. 10 12489
Berlin, Germany
www.qt.io
Geschäftsführer: Mika
;ll have BC issues from that, too.
References:
- https://bugreports.qt.io/browse/QTBUG-119901
-
https://codereview.qt-project.org/c/qt/qtbase/+/478199/comment/bcbe8aca_d5d65018/
- https://codereview.qt-project.org/c/qt/qtbase/+/507383
Opinions? Comments?
Thanks,
Marc
--
Marc Mutz
Principal
age
https://codereview.qt-project.org/c/qt/qtbase/+/523363, it's already
approved and just waits for a user.
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 Li
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
gt;>
>> My 2 c,
>> --
>> Giuseppe D'Angelo | giuseppe.dang...@kdab.com | Senior Software Engineer
>> KDAB (France) S.A.S., a KDAB Group company
>> Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com/
>> KDAB - The Qt, C++ and OpenGL Experts
>>
>>
to out-of-line. If either side is inline, it'll do the right thing on its
> own.
Yes. If either side is inline, you still get the conversion operators
emitted in debug mode, which Qt tends to optimize for, too. That's one
of the reasons why, even with {std,Qt}::_ordering types being B
have a
`using std::...`, yet, so we're still ok, and QTestLib doesn't have BC
constraints).
The Qt::*ordering types, OTOH, are specifically _for_ use in the ABI.
Thanks,
Marc
--
Marc Mutz
Principal Software Engineer
The Qt Company
Erich-Thilo-Str. 10 12489
Berlin, Germany
www.qt.io
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;
>
ies
will just increase the porting overhead for our users. In no universe
would that be good for our users. We know where we need to go: no
Qt::ordering classes, only std::ordering, and anything that distracts
either our users or ourselves from that goal is counter-productive.
Thanks,
Marc
--
t right than getting it soon.
We're discussing various tangential aspects for half a year now. At some
point, all the cards are on the table and all that talking needs to come
to some conclusion.
That point is now.
Thanks,
Marc
--
Marc Mutz
Principal Software Engineer
The Qt Company
Eric
ment 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, German
absence of
`-fvisibility=hidden -fvisibility-inlines-hidden`?
- does making the Qt and std::ordering types BC with each other not
solve the problem in this case, too?
Thanks,
Marc
--
Marc Mutz
Principal Software Engineer
The Qt Company
Erich-Thilo-Str. 10 12489
Berlin, Germany
www.qt.io
Geschäfts
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
gt; this code base even before they officially became part of Qt. I am glad they
> agreed to continue this work going forward in the context of Qt Development.
>
> --
> Alex
>
--
Marc Mutz
Principal Software Engineer
The Qt Company
Erich-Thilo-Str. 10 12489
Berlin, Germany
www
project.org/q/owner:jaishree.vyas%40qt.io
> <https://codereview.qt-project.org/q/owner:jaishree.vyas%40qt.io>
> As reviewer:
> https://codereview.qt-project.org/q/reviewer:jaishree.vyas%2540qt.io
> <https://codereview.qt-project.org/q/reviewer:jaishree.vyas%2540qt.io>
>
> //!
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
the Qt functions can switch between the two return type families. But you
> can't overload operators, so operators must return one family only.
--
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 V
27;t like 2. It has it all backwards.
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 Charlo
s) if
there is no "API" for doing this on his data members? As a concrete
example, how is the author of a `struct QFoo { int; QString; }` supposed
to implement his cmp() if all he gets is op<=>, a C++20-only API?
I don't see how we can manage without an API for doing three-way
c
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 1026 matches
Mail list logo
