of Qt Creator got to a QString's QArrayData through a
clearly-marked private API.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Principal Engineer - Intel Platform & System Engineering
smime.p7s
Description: S/MIME cryptographic signature
--
Development mailing list
Deve
n
upcoming change of mine too. And renaming it back is likewise gratuitous: I
did it because it was easier to fix *my* own build.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Principal Engineer - Intel Platform & System Engineering
smime.p7s
Description: S/MIME cryptographic si
as Qt3D.
They're just no-op on Linux. As Tim said in his reply, applications can
request RT priority from RTKit.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Principal Engineer - Intel Platform & System Engineering
smime.p7s
Description: S/MIME cryptographic signature
--
De
iews and static analyses anyway for your application running as root that
this is not an undue burden.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Principal Engineer - Intel Platform & System Engineering
smime.p7s
Description: S/MIME cryptographic signature
--
Development mail
o complain about this. That's how I found and fixed the misses
back in the day. That has probably been lost since the conversion to C++,
because like the other changes it wasn't actually merged.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Principal Engineer - In
mment in the change
above with the code that worked.
For all the platforms that don't respond before change integrates, feel free
to submit changes later.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Principal Engineer - Intel DCAI Platform & System Engineering
smim
On Thursday, 15 May 2025 10:35:46 Pacific Daylight Time Thiago Macieira wrote:
> CMake Error at tests/auto/wayland/shared/CMakeLists.txt:61
> (target_link_libraries):
> Target "SharedClientTest" links to:
>
> Wayland::Server
>
> but the target was not f
On Thursday, 15 May 2025 08:44:40 Pacific Daylight Time Thiago Macieira via
Development wrote:
> On Thursday, 15 May 2025 08:31:12 Pacific Daylight Time Fabian Kosmale via
>
> Development wrote:
> > this is a known issue, and
> > https://codereview.qt-project.org/c/qt/qtbas
errors until the corresponding patch is merged there.
I can hold off a full rebuild for a while.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Principal Engineer - Intel DCAI Platform & System Engineering
smime.p7s
Description: S/MIME cryptographic signature
--
Development mailing
t tests/auto/wayland/shared/CMakeLists.txt:40
(qt6_generate_wayland_protocol_server_sources):
Unknown CMake command "qt6_generate_wayland_protocol_server_sources".
--
Thiago Macieira - thiago.macieira (AT) intel.com
Principal Engineer - Intel DCAI Platform & System Engineering
On Friday, 9 May 2025 15:59:35 Central European Summer Time Volker Hilsheimer
via Development wrote:
> Our future AI overlord says:
I tried classnamer.org for about 100 tries, and the best it came up with was
ResponsibleMetadataCollector, so I suggest QResponsibleMetadataItemModel
--
Thi
On Tuesday, 22 April 2025 09:46:40 Pacific Daylight Time Scott Bloom wrote:
> Or is non-ninja not truly supported yet and this is a known issue?
Only Ninja is supported.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Principal Engineer - Intel DCAI Platform & System Engi
the typeinfo, but it does not
require *using* it as the discriminator. Implementations that support shared
libraries and DLLs should be fixed to compare type names like QMetaType does.
I mean, we do have 20 years of experience with this, since Qt 4.0.
--
Thiago Macieira - thiago.macieira (AT) intel.co
On Friday, 4 April 2025 11:15:35 Pacific Daylight Time Thiago Macieira wrote:
> BTW, I said we "have the same problem with QMetaType", but in reality we
> don't because we take this into account.
> friend bool comparesEqual(const QMetaType &lhs,
>
ould definitely not do a name comparison for types in unnamed
namespaces (types whose name start with "{anonymous}::" or "(anonymous
namespace)::"
--
Thiago Macieira - thiago.macieira (AT) intel.com
Principal Engineer - Intel DCAI Platform & System Engineering
smime.p7s
De
recognise shared
libraries & DLLs exist, so this is an area that is underdeveloped. Despite
being the mainstream.
IMNSHO, this needs to be addressed in the Standard, ahead of modules even.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Principal Engineer - Intel DCAI Platform & Sys
but we think C++26 reflection will not be
enough yet. We'll probably have to write some papers for reflection to catch up
to Minimum Viable Product by C++29.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Principal Engineer - Intel DCAI Platform & System Engineering
smime.
quot;your text") and you
> might want to use the Qt::StringLiterals namespace.
Indeed, it is much nicer to write:
"latin1 or ascii text"_L1
u"any text"_s
--
Thiago Macieira - thiago.macieira (AT) intel.com
Principal Engineer - Intel DCAI Platform & Syst
r a must-have later in the
tree. Skipping them causes the conflicts that Marc is complaining about.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Principal Engineer - Intel DCAI Platform & System Engineering
smime.p7s
Description: S/MIME cryptographic signature
--
Development mailing l
e shall
abide by your recommendations.
[1] 7df128675a22391bc3ade2a45b558bc38eee1c67
[2] 34f60877bdb54786c62fd1bf5b44a81430aa411f
--
Thiago Macieira - thiago.macieira (AT) intel.com
Principal Engineer - Intel DCAI Platform & System Engineering
smime.p7s
Description: S/MIME cryptographic signature
--
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
t match supported non-Server versions should "just
work".
--
Thiago Macieira - thiago.macieira (AT) intel.com
Principal Engineer - Intel DCAI Platform & System Engineering
smime.p7s
Description: S/MIME cryptographic signature
--
Development mailing list
Development@qt-project.o
turns the word into a macro that expands to empty:
Q_PROPERTY_FULL(int, READ int value() noexcept,
WRITE void setValue(int),
NOTIFY void valueChanged())
--
Thiago Macieira - thiago.macieira (AT) intel.com
Principal Engineer - Intel DCAI Platform & Sy
ll QtCore maintainer-discretion decisions applying to LTS
branches of any kind to Marc. He has far more visibility into what is in those
branches than I do, and he has a vested interest in both improving them and
keeping them stable, so I trust he will make the correct decisions.
--
Thiago
rrect path (assuming the file is arch-independent, which the
discussion here seems to indicate it is).
--
Thiago Macieira - thiago.macieira (AT) intel.com
Principal Engineer - Intel DCAI Platform & System Engineering
smime.p7s
Description: S/MIME cryptographic signature
--
Dev
Jan 11th), and the new tool crashes qsb
> when building qtdeclarative.
We can switch to QT_HOST_TOOLS builds in Coverity, so we don't run the
Coverity-built tools while building the code for Coverity to scan.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Principal Engineer
this recommendation for the guard macros.
But I support the rule of using the module name.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Principal Engineer - Intel DCAI Platform & System Engineering
smime.p7s
Description: S/MIME cryptographic signature
--
Development mailing list
> But what about Q_ENUM_NS and Q_FLAG_NS?
Those work, but they show up in the namespace's meta object and you must have
the Q_NAMESPACE macro.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Principal Engineer - Intel DCAI Platform & System Engineering
smime.p7s
Des
y can't be extracted by moc using Q_FLAG /
Q_ENUM. The enumeration values must be in the class body for moc to work.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Principal Engineer - Intel DCAI Platform & System Engineering
smime.p7s
Description: S/MIME cryptographic si
nscoped enum would simply move the "Option" from the middle to the end, with
little space saved.
But at this point I am not in favour of mandating them for all new
enumerations. There are still too many cases where they don't make sense. And
we definitely are not in a place to sugg
On Thursday 16 January 2025 04:55:56 Pacific Standard Time Marc Mutz via
Development wrote:
> https://gcc.godbolt.org/z/6exEonP5o, maybe?
Yes.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Principal Engineer - Intel DCAI Platform & System Engineering
smime.p7s
Description:
, I consider the matter resolved now that QStringConverter supports
other codecs. You need to enable ICU; I don't consider that to be a high price
at all.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Principal Engineer - Intel DCAI Platform & System Engineering
smime.p7s
Descript
ot;Qt N Compat" moniker and
> artificially binding them together.
If we're going to keep those classes in Qt 7, then indeed they should be in a
library that has a better name. As a library, Qt5CoreCompat must go in Qt 7.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Principal Eng
ext release. There may be some
exceptions that we think even N years being deprecated isn't long enough
(e.g., it's been around since Qt 1, such as QTimer).
--
Thiago Macieira - thiago.macieira (AT) intel.com
Principal Engineer - Intel DCAI Platform & System Engineering
smime.p
uot;
programming, you want to generate code to generate the binding more efficiently
than to add to the meta objects. See the Qt for Python's shiboken for some
help here.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Principal Engineer - Intel DCAI Platform & System Engineering
rk on qtscxmlc today as I had wanted. I spent time trying to
figure out thread_local on Windows, again.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Principal Engineer - Intel DCAI Platform & System Engineering
smime.p7s
Description: S/MIME cryptographic signature
--
Developm
builds, I propose we disable cpp-winrt for
all static builds or for C++17 static builds. And make MSVC build with C++20
by default.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Principal Engineer - Intel DCAI Platform & System Engineering
smime.p7s
Description: S/MIME cryptogra
yses of the problem are welcome too.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Principal Engineer - Intel DCAI Platform & System Engineering
smime.p7s
Description: S/MIME cryptographic signature
--
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
On Tuesday 26 November 2024 08:58:38 Pacific Standard Time Thiago Macieira
wrote:
> That being the case, I'm just not going to do anything. Not my problem any
> more to move us forward. That also means I will not be doing the work to
> test our headers in C++23 mode either - th
On Monday 28 October 2024 09:14:43 Pacific Standard Time Thiago Macieira wrote:
> Of course.
>
> But you understood my general goals and, so long as I keep to them as Volker
> is requesting, neither you nor anyone else had a problem.
Update:
Re: https://bugreports.qt.io/browse/QTBUG-
On Monday 25 November 2024 08:45:55 Pacific Standard Time Thiago Macieira
wrote:
> > The issue would probably not happen in a release build
>
> It does happen. I'll disable namespace 0 for MSVC.
https://codereview.qt-project.org/c/qt/qtopcua/+/606509
If you need this fun
It does happen. I'll disable namespace 0 for MSVC.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Principal Engineer - Intel DCAI Platform & System Engineering
smime.p7s
Description: S/MIME cryptographic signature
--
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
e
past tense and explains to a user reading the changelog what changed for them;
usually a "fixed a bug that ..." is a good start. The message body should
explain why you're making this particular change, not describe the code. We
can read diffs :-)
--
Thiago Macieira - thiago.mac
7;m just saying that CMake 3.26 has just too many negatives in its camp. So if
Alexandru can hold off for one more release, those negatives go away.
On the other hand, if he says "Sune is the only developer who would be affected
and only for 6 months, isn't contributing anyway, and t
le to compile Qt from source should have no trouble building CMake
> themselves either, so I don't get why libraries stay on ancient versions
> of CMake just because some users might not have a newer version by default.
Barrier of entry.
--
Thiago Macieira - thiago.macieira (AT) in
't have to be constrained by the
> old yocto lts version, but i'm waiting for confirmation from above whether
> it's very important for QtC.
We still have the Debian stable problem, though.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Principal Engineer - Intel
LTS should align to the current Yocto LTS and stop there.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Principal Engineer - Intel DCAI Platform & System Engineering
smime.p7s
Description: S/MIME cryptographic signature
--
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
der CMake version.
Downgrading CMake should not be allowed, the same way that downgrading GCC or
glibc isn't. The CMake that is found in the build environment is as old as is
allowed for anything built against the Qt that this CMake built.
--
Thiago Macieira - thiago.macieira (AT) intel.c
g on something else in qtscxml.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Principal Engineer - Intel DCAI Platform & System Engineering
smime.p7s
Description: S/MIME cryptographic signature
--
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
ully self-contained and can be
> installed in parallel to system-provided cmake.
Installing binaries compiled by someone other than the Linux distribution (and
thus signed by their repository key) is a non-starter.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Principal Engineer - Intel D
ble and Debian oldstable are *too* new. Their glibc
versions are respectively 2.36 and 2.31. Your best bet for "old distro" right
now is RHEL/CentOS/Rockylinux 8, which comes with glibc 2.28 but CMake 3.26.5,
though you'll need to upgrade its GCC from 8.5.
--
Thiago Macieira - thiag
id not
see anything in my builds of Qt, but I only build qtbase for Mac and Windows
(aside from activeqt, which we're managing).
--
Thiago Macieira - thiago.macieira (AT) intel.com
Principal Engineer - Intel DCAI Platform & System Engineering
smime.p7s
Description: S/MIME cryptograp
On Monday 28 October 2024 08:40:25 Pacific Daylight Time Andreas Aardal Hanssen
wrote:
> Man 28 okt 2024 kl. 16:29 skrev Thiago Macieira:
> > Lazy consensus is part of our governance. If no one speaks up with
> > arguments against, it implies no one has arguments agains
s a beer count, I'll provide it :)
Our current rules should be more than enough to prevent unintentional use of
their ABI in ours.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Principal Engineer - Intel DCAI Platform & System Engineering
smime.p7s
Description: S/MIME cryptographic sig
arguments against of sufficient interest to them
to voice in the first place. Lack of interest and apathy imply people don't
care enough one way or the other.
I am not asking for additional configurations in the CI.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Principal Engi
ds to C++20, as described in
the earlier email. How many we maintain at C++17 is TBD and can be as low as
zero.
Header-checking for C++17 will be implemented.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Principal Engineer - Intel DCAI Platform & System Engineering
smime.p7s
Descri
On Friday 18 October 2024 08:36:22 Pacific Daylight Time Thiago Macieira wrote:
> I'm going to assume that silence is consent to "there is no drawback" and
> will proceed with the implementation.
It's been a week since I posted this, so as soon as I find the time to sati
t;, n).arg(n) // localized and
> > pluralized
>
> We likely need to find a way to support this as well?
trFormat("You bought a total of {:Ln} apple(s)", Qt::Cardinality(n));
--
Thiago Macieira - thiago.macieira (AT) intel.com
Principal Engineer - Intel DCAI Platform &
matter("{a:L}").arg(QStringFormatter::qArg("a",
> 15.5) but overly wordy)
I think this has become Obsoleted By Events.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Principal Engineer - Intel DCAI Platform & System Engineering
smime.p7s
Description: S/MIME crypto
On Thursday 24 October 2024 10:12:35 Pacific Daylight Time Thiago Macieira
wrote:
> > IMO, we could benefit from the new syntax, if we could build our
> > implementation on top of what the standard provides for us. But I see
> > little benefit in reimplementing the standard from
ert, to get their opinions. Adding
Nicolas now.
See also my question about using locale digits. Because yes, there may be
formatting mods that the translator supplies.
As it stands, I think:
* translatable text should not use padding, trimming & filling
* ideally we'd compile-ti
cluding possible extensions (like
> f-strings, just proposed in https://wg21.link/p3412r0 ).
Which means analysing it now to see if it could be used for translatable
strings in the future.
Because, as it is written, it isn't clear that it's useful. The paper shows a
basic_string
nge in the template string.
If possible, yes, I'd like to confirm that the string you typed in the source
has the correct number of replacement requirements as parameters were passed
in. Then tooling can verify that the translators have done the correct job and
not used more than what wa
ding and
filling. The original string in Engineering English was {:%T}, which means no
padding and no filling. Are the translators allowed to change it?
--
Thiago Macieira - thiago.macieira (AT) intel.com
Principal Engineer - Intel DCAI Platform & System Engineering
smime.p7s
Description: S/MIME cryptographic signature
--
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
e'll act on it. I asked Phil to
submit the change to Gerrit, because I realised my last reply may be wrong.
This needs discussion of what's happening and how to properly fix it.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Principal Engineer - Intel DCAI Platform & Syste
nslated strings, but if we want to have the machinery only once and
behaviour-compatible, we need to know what it will be before we start
supporting std::format().
This begs the question for our string formatters: should we default to quoted
& escaped? C++23 introduces the "?"
ot handle template names
> and so fails with dynamically created properties.
This is the bug.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Principal Engineer - Intel DCAI Platform & System Engineering
smime.p7s
Description: S/MIME cryptographic signature
--
Development mailing lis
On Monday 14 October 2024 10:31:22 GMT-7 Thiago Macieira wrote:
> On Monday 14 October 2024 09:53:56 GMT-7 Thiago Macieira wrote:
> > > The last time we discussed this was at QtCS24
> > > (https://wiki.qt.io/QtCS2024_C%2B%2B20), where IIRC the conclusion was
> > &g
ok worse with
concepts than with their current private template aliases using
std::enable_if.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Principal Engineer - Intel DCAI Platform & System Engineering
smime.p7s
Description: S/MIME cryptographic signature
--
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
On Monday 14 October 2024 09:53:56 GMT-7 Thiago Macieira wrote:
> > The last time we discussed this was at QtCS24
> > (https://wiki.qt.io/QtCS2024_C%2B%2B20), where IIRC the conclusion was
> > that
> > ATM, there is no reason to switch to C++20. So, it is definitely not i
this build. There are only people from The Qt Company so far
> on it. If someone else is interested, I would gladly change this and
> include other people ;-)
I seriously doubt that. Every time I mistakenly forget a typename or use
another C++20 feature, the build fails immediately in the CI.
uot;pretend" that we require C++17 but in reality we just check
> that we can pass `-std=c++17` to the compiler. Any usage in Qt code of
> individual language/library features still requires protection, because
> they're not universally implemented.
Indeed, except
et for C++20-enabled builds
check each header in both modes. Maybe add C++23 there too.
6) when should we do this?
The last time we discussed C++20, it was made clear that we can only do such
changes on LTS+1 releases. That's 6.9.
--
Thiago Macieira - thiago.macieira (AT) inte
-project.org/c/qt/qtbase/+/596122 merges.
That bug is probably why ActiveQt's dumpcpp.exe was crashing. I can now run it
without crashing.
ActiveQt still doesn't pass the CI, but the issue is fixed.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Principal Engineer - Intel
gt; get that by the reviewers silence itself, I guess a little amount of
> people ping for years or go to mailing list.
You're generalising. The fact that those contributions weren't wanted or were
misunderstood is not an indication that everyone's contributions will suffer
the
of this week, 13), which
requires that QMetaEnums have their meta objects.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Principal Engineer - Intel DCAI Platform & System Engineering
smime.p7s
Description: S/MIME cryptographic signature
--
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
that was passed to your type to access the
extra fields.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Principal Engineer - Intel DCAI Platform & System Engineering
smime.p7s
Description: S/MIME cryptographic signature
--
Development mailing list
Development@qt-project.org
https://
cally register an enum with the meta-type
> system (so that QMetaEnum.metaType().isValid() returns true)?
Sure. And registration is automatic anyway.
All you should need to do is pass the necessary QMetaType
--
Thiago Macieira - thiago.macieira (AT) intel.com
Principal Engineer - Intel DCAI
he metatype of properties and methods
Additionally Metatypes for enums and properties are mandatory too. For
methods, they are allowed to be nullptr.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Principal Engineer - Intel DCAI Platform & System Engineering
smime.p7s
Description: S/MIM
to the meta-object. It would
> be nice to be able to register an enum with the meta-type system
> dynamically.
Or you can set the EnumOrFlag flag in the QMetaProperty flags field to force
the
constructor to search.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Principal Engineer -
he release is near.
The feature system is not guaranteed to work. If you use *any* -no-feature
option, you assume responsibility for submitting build fixes. This task didn't
get assigned to me, but if it had been, I'd have closed it with that.
--
Thiago Macieira - thiago.macieir
On Tuesday 1 October 2024 07:53:13 GMT-7 Thiago Macieira wrote:
> Update: this is a real regression. However, meta objects for private classes
> weren't working properly before either, so this only changed what fails.
>
> Tracking in https://bugreports.qt.io/browse/QTBUG-129570
On Tuesday 1 October 2024 07:53:13 GMT-7 Thiago Macieira wrote:
> Update: this is a real regression. However, meta objects for private classes
> weren't working properly before either, so this only changed what fails.
>
> Tracking in https://bugreports.qt.io/browse/QTBUG-129570
On Monday 30 September 2024 15:22:48 GMT-7 Thiago Macieira wrote:
> 2) Jøger reports that VS is failing to compile the meta object of a private
> class. I think that's a compiler bug, because there is an equivalent test in
> tst_Moc and that compiles. I can't reproduce the is
On Thursday 12 September 2024 06:59:55 GMT-7 Thiago Macieira wrote:
> > +1 for that! That's one of the things that we pay attention to during API
> > review in Qt, so hopefully all new Qt APIs will either use `enum class`,
> > or explicitly define an underlying type.
>
t a git show of this commit shows the annotation:
Notes (cherry-picks):
6.7: 8dd7aba7fd2e6edeee33e97879f7e891028bad7d
And that commit is name-rev'ed to tags/v6.7.0-rc1~141.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Principal Engineer - Intel DCAI Platform & System Engineering
smime.p7s
a76dec51de48af99132b91 (which is dated over 3 months before
the first public commit) and Marius S-O wrote:
Add hardcoded qclass_lib_map.h based on 4.8
This is only until UIC/Designer handles this properly
Permanent temporary...
--
Thiago Macieira - thiago.macieira (AT) intel.com
er we have to write
the keyword or not).
That said, the inline keyword can be omitted for functions, so moving it to
the right where we usually won't try to grep makes some sense.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Principal Engineer - Intel DCAI Platform & System
On Thursday 19 September 2024 08:07:19 GMT-7 Thiago Macieira wrote:
> On Thursday 19 September 2024 01:11:54 GMT-7 Halla Rempt wrote:
> > Who knows whether anyone is using it? There are zillions of projects using
> > Qt out in the world, but the people developing Qt keep assuming
submitting to useless clean-ups that nobody
> seems to have thought were an imposition. I've been through Qt1..2..3..4..5
> and now going through 6.
And the reports we've had is that however painful this transition is, it's the
least painful of all.
--
Thiago Macie
> also inline.
Yeah, but by the same token you could be searching for static inline, of which
we have far more in our sources.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Principal Engineer - Intel DCAI Platform & System Engineering
smime.p7s
Description: S/MIME cryptographi
to adopt.
Arthur doesn't conclude very well whether constinit comes all the way first
(because it modifies how the initialisation happens) versus being placed where
constexpr would be.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Principal Engineer - Intel DCAI Platform & S
> Whether inline or constexpr comes first has none, IMNSHO.
I'm thinking of new code and how we usually write code. We don't enforce the
static inline / inline static, for example, but most people write the former.
I'm just wondering which one we prefer.
--
Thiago Mac
erefore, our constexpr variables should be explicitly inline too, to avoid
those problems. The question is only the order in which we spell those two
keywords out.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Principal Engineer - Intel DCAI Platform & System Engineering
smime.p7s
p 'static constexpr inline' \* '!*/3rdparty/*' | wc -l
57
$ git sgrep 'static inline constexpr' \* '!*/3rdparty/*' | wc -l
53
$ git sgrep 'inline static constexpr' \* '!*/3rdparty/*' | wc -l
16
$ git sgrep 'inline constexpr stat
ttps://codereview.qt-project.org/c/qt/qtbase/+/586454:
QMetaMethod: make some QByteArray-returning methods slightly faster
--
Thiago Macieira - thiago.macieira (AT) intel.com
Principal Engineer - Intel DCAI Platform & System Engineering
smime.p7s
Description: S/MIME cryptographic signatur
On Tuesday 10 September 2024 10:33:32 GMT-7 Thiago Macieira wrote:
> Is this supported? I didn't know about it until yesterday. I doubt anyone is
> using it, though it's possible some code carried over from Qt 3 was left
> unmodified like that.
QGroupBox:
Q_PROPERTY(Qt::
On Tuesday 10 September 2024 10:12:10 GMT-7 Andreas Aardal Hanssen wrote:
> Tir 10 sep 2024 kl. 18:55 skrev Thiago Macieira:
> > Any objections?
>
> Please don’t break source compatibility?
It does appear that a Q_PROPERTY of a Q_FLAG whose getter and setter operate
on integers
On Tuesday 10 September 2024 09:55:24 GMT-7 Thiago Macieira wrote:
> 1) I will fix moc to *not* manipulate int for property enum types, which
> means it will not use QFlag at all
https://codereview.qt-project.org/c/qt/qtbase/+/589897
If we need to keep compatibility with integer gette
if'ed on sizeof(QFlags) == sizeof(int)
4) I will not mark them or QFlag as deprecated
Any objections?
--
Thiago Macieira - thiago.macieira (AT) intel.com
Principal Engineer - Intel DCAI Platform & System Engineering
smime.p7s
Description: S/MIME cryptographic signature
--
Development
On Tuesday 10 September 2024 04:56:40 GMT-7 Thiago Macieira wrote:
> In Qt 3, QVariant could only contain a closed set of types, so QObject::
> QObject::setProperty would only be able to write QFlags if the QVariant
> contained an int, and QMetaProperty already had isEnumType() at
1 - 100 of 3571 matches
Mail list logo
