We could use C++23 features in 2025 that were supported in 2020 compilers. I'm
just arguing that there aren't any that are worth the trouble.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Cloud Software Architect - Intel DCAI Cloud Engineering
smime.p7s
Description: S/MIME cryptograp
On Thursday, 4 May 2023 00:52:47 PDT Marc Mutz via Development wrote:
> On 04.05.23 00:39, Thiago Macieira wrote:
> > And yet, the list of things we want from C++20 is not that big. It's
> > nowhere as complex as C++11 and I'd argue that even the 17 upgrade for Qt
> > 6.0 was
d. I don't see anything in 23
that we'd push for.
And yet, the list of things we want from C++20 is not that big. It's nowhere
as complex as C++11 and I'd argue that even the 17 upgrade for Qt 6.0 was a
bigger jump. Unless we add concepts to the list, but I don't think we can
until we've experime
g with a new version of the library and running with an old one is not
and has never been supported. No one is suggesting that. That's why I listed a
few oldest minimum versions, so that anyone interested in creating binary
builds could choose exactly those.
--
Thiago Macieira - thi
cquire = memory_order::acquire;
inline constexpr memory_order memory_order_release = memory_order::release;
inline constexpr memory_order memory_order_acq_rel = memory_order::acq_rel;
inline constexpr memory_order memory_order_seq_cst = memory_order::seq_cst;
--
Thiago Macieira - thiago.ma
e class, as our current practice dictates, with the choice of plain enum or
enum class.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Cloud Software Architect - Intel DCAI Cloud Engineering
smime.p7s
Description: S/MIME cryptographic signature
--
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
hey're sufficiently descriptive already.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Cloud Software Architect - Intel DCAI Cloud Engineering
smime.p7s
Description: S/MIME cryptographic signature
--
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
13;
std::source_location with libc++ 16, etc.). At best, we'd have the exact same
feature set I proposed for C++20, except we'd compile with -std=c++23.
So, no, I think we should aim for the feature set I posted yesterday from
C++20. The question is only when.
--
Thiago Macieira - thiago.macie
-apple-darwin21.6.0
Thread model: posix
InstalledDir: /Applications/Xcode.app/Contents/Developer/Toolchains/
XcodeDefault.xctoolchain/usr/bin
Wed May 3 09:33:46 PDT 2023
I don't know if it's *functional* to the point we'd need it, but we won't know
until we try.
--
Thiago Macieira - thiago.ma
r non-LTS
users. The first of your LTS to require it would be the one from October 2024,
and it wouldn't become the oldest LTS until 3 years after 6.5 (March 2026).
--
Thiago Macieira - thiago.macieira (AT) intel.com
Cloud Software Architect - Intel DCAI Cloud Engineering
smime.p7s
Des
bility with that version in the CI...).
Sorry, I can't help you there (literally).
--
Thiago Macieira - thiago.macieira (AT) intel.com
Cloud Software Architect - Intel DCAI Cloud Engineering
smime.p7s
Description: S/MIME cryptographic signature
--
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
ink we're before 1.
I'd propose we move to #1 immediately, for 6.6: we build with C++20 if the
compiler supports C++20.
See also https://codereview.qt-project.org/c/qt/qtbase/+/463425
--
Thiago Macieira - thiago.macieira (AT) intel.com
Cloud Software Architect - Intel DCAI Cloud Engineering
w, we can't
do that and we must provide certain workarounds.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Cloud Software Architect - Intel DCAI Cloud Engineering
smime.p7s
Description: S/MIME cryptographic signature
--
Development mailing list
Development@qt-project.org
https://lists
match the feature list above, with minimal
workarounds.
Opinions?
--
Thiago Macieira - thiago.macieira (AT) intel.com
Cloud Software Architect - Intel DCAI Cloud Engineering
smime.p7s
Description: S/MIME cryptographic signature
--
Development mailing list
Development@qt-project.org
https
hat the issues are for ourselves, before we make time promises.
I expect we'll need more than 1.5 year of advance notice that the opt-in will
change to opt-out.
> (d) is something I would do for Qt 7, as that’s the correct time to do those
> changes and clean up our code base
I also think
On Monday, 20 March 2023 08:44:30 CDT Edward Welbourne wrote:
> Thiago Macieira (31 October 2019 22:11) wrote [0]:
> > This RFC (...) is meant to discuss how we'll deal with locales on Unix
> > systems on Qt 6. This does not apply to Windows because on Windows we
> > cannot r
of the page. It lists not just one proper clone URL,
but three (two of which you shouldn't use, because they aren't encrypted).
Now, it would be nice if the clone and the web URL version were the same.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Cloud Software Architect - Intel D
ia files and via pipes to
child processes. So yes, finding out what the legacy ACP is might be a useful
piece of information. It shouldn't be the toLocal8Bit encoding, but it should
be available should the need arise.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Cloud Software Archit
Question: which category does Qt Creator fall into?
--
Thiago Macieira - thiago.macieira (AT) intel.com
Cloud Software Architect - Intel DCAI Cloud Engineering
smime.p7s
Description: S/MIME cryptographic signature
--
Development mailing list
Development@qt-project.org
https://lists.qt-proj
r our own applications?
--
Thiago Macieira - thiago.macieira (AT) intel.com
Cloud Software Architect - Intel DCAI Cloud Engineering
smime.p7s
Description: S/MIME cryptographic signature
--
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
tal: internal server error
--
Thiago Macieira - thiago.macieira (AT) intel.com
Cloud Software Architect - Intel DCAI Cloud Engineering
smime.p7s
Description: S/MIME cryptographic signature
--
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
On Thursday, 16 March 2023 08:58:35 PDT Ilya Fedin wrote:
> On Thu, 16 Mar 2023 07:55:37 -0700
>
> Thiago Macieira wrote:
> > If Q_NOREPLY were [[qt::no_reply]], where would the correct place be?
>
> Isn't the goal to move it where it was previously? Before [1] it was
>
NOREPLY void " rather than
> "inline void Q_NOREPLY "?
If Q_NOREPLY were [[qt::no_reply]], where would the correct place be?
--
Thiago Macieira - thiago.macieira (AT) intel.com
Cloud Software Architect - Intel DCAI Cloud Engineering
smime.p7s
Description: S/MIME cryptographic signat
On Monday, 13 March 2023 09:51:00 PDT Thiago Macieira wrote:
> On Monday, 13 March 2023 08:46:03 PDT Fabian Kosmale via Development wrote:
> > Hi,
> >
> > I can look into fixing this from the moc side. Is there any smaller,
> > self-contained reproducer than KWal
ist);
}
the other generates
public Q_SLOTS: // METHODS
void Q_NOREPLY Method();
--
Thiago Macieira - thiago.macieira (AT) intel.com
Cloud Software Architect - Intel DCAI Cloud Engineering
foo.xml
Description: XML document
smime.p7s
Description: S/MIME cryptographic signature
--
De
QtPrivate::TypeAndForceComplete,
Since I've already moved Q_NOREPLY to where it was, I don't know what's wrong.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Cloud Software Architect - Intel DCAI Cloud Engineering
smime.p7s
Description: S/MIME cryptographic signature
--
Deve
ng to be more work
than keep going now.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Cloud Software Architect - Intel DCAI Cloud Engineering
smime.p7s
Description: S/MIME cryptographic signature
--
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
in branch at all.
Pretty sure reverting now would be even more disruptive than just fixing the
remaining issues. It does mean Qt 7 anyway.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Cloud Software Architect - Intel DCAI Cloud Engineering
smime.p7s
Description: S/MIME cryptographic
course.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Cloud Software Architect - Intel DCAI Cloud Engineering
smime.p7s
Description: S/MIME cryptographic signature
--
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
to be tested.
In 2 weeks time, I'll disable the DSP version that didn't get a fix or "cannot
reproduce".
--
Thiago Macieira - thiago.macieira (AT) intel.com
Cloud Software Architect - Intel DCAI Cloud Engineering
smime.p7s
Description: S/MIME cryptographic signature
--
Developme
On Sunday, 5 March 2023 06:26:08 PST Turritopsis Dohrnii Teo En Ming wrote:
> I discovered that Magix Movie Studio 2023 Platinum uses open source Qt 5.
What's your evidence?
--
Thiago Macieira - thiago.macieira (AT) intel.com
Cloud Software Architect - Intel DCAI Cloud Engineering
smime.
ent.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Cloud Software Architect - Intel DCAI Cloud Engineering
smime.p7s
Description: S/MIME cryptographic signature
--
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
also get with YAML. And since YAML is just a "front-end" to JSON in
most cases, you can use all the JSON tools to query and manipulate the
contents, like jq and jp.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Cloud Software Architect - Intel DCAI Cloud Engineering
smime.p7s
existing
> qt_attributionsscanner.json files to a new format is worth the time.
> Unless, of course, somebody volunteers
I can volunteer to patch qtattributionsscanner to run a small Python script to
convert from YAML to JSON before the parsing.
--
Thiago Macieira - thiago.macieira (AT) intel.com
switching to YAML?
Those files are consumed by qtattributionsscanner. That looks like a very
simple application that can be rewritten in Python, or it could launch Python
or yq to convert YAML to JSON on the fly.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Cloud Software Architect - Intel D
On Sunday, 12 February 2023 22:15:26 PST Tomi Korpipää via Development wrote:
> The plan is to have QtGraphs as a technology preview in Qt 6.6, maturing it
> for Qt 6.7.
So you've got a lot of content already. Can you point to the Labs repository?
--
Thiago Macieira - thiago.ma
we get an overview of what the issues with it are, why they
can't be fixed, and how this new module proposes to fix that?
And just how do you plan on finishing it in the next 2 months?
--
Thiago Macieira - thiago.macieira (AT) intel.com
Cloud Software Architect - Intel DCAI Cloud Engineering
smi
On Tuesday, 31 January 2023 15:21:47 PST Thiago Macieira wrote:
> If it's not going to be in the near future, I *can* modify the patch to
> detect that the new system call is not implemented and then fall back to
> the old one. That would mean that every contended mutex or semaphore wil
could happen anyway. But it does simplify calculations,
so it's a win.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Cloud Software Architect - Intel DCAI Cloud Engineering
smime.p7s
Description: S/MIME cryptographic signature
--
Development mailing list
Development@qt-project
On Monday, 6 February 2023 11:37:07 PST Thiago Macieira wrote:
> On Monday, 6 February 2023 11:21:13 PST Lisandro Damián Nicanor Pérez Meyer
>
> wrote:
> > When building qtbase 6.4.2 on Debian I see:
> >
> > In member function ‘__ct ’,
> >
> > in
ft 7 (SpanShift) zeroes
in. That means the maximum value that nSpans could assume is 2^(64-7) - 1.
If you multiply that value by sizeof(Span) == 144, that would overflow the
size_t though.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Cloud Software Architect - Intel DCAI Cloud
2019, we need Qt Creator to start
using 2022.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Cloud Software Architect - Intel DCAI Cloud Engineering
smime.p7s
Description: S/MIME cryptographic signature
--
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
On Tuesday, 31 January 2023 15:00:07 PST Thiago Macieira wrote:
> As most of you are aware, a signed 32-bit time_t overflows in 2038. Linux
> has recently deployed "time64_t" (by certain values of "recently", as in
> 2015, see [1])
> I don't know if this is an
If there's no action within one month, I'll abandon the patch, close the task
as "Won't Do" and declare 32-bit Qt will not work past 2038.
[1] https://lwn.net/Articles/664800/
--
Thiago Macieira - thiago.macieira (AT) intel.com
Cloud Software Architect - Intel DCAI Cloud Engineering
On Tuesday, 24 January 2023 00:44:37 PST Marc Mutz via Development wrote:
> On 23.01.23 23:57, Thiago Macieira wrote:
> > static_assert(sizeof(std::chrono::milliseconds::rep) == 8);
>
> Why == and not >=?
I think we'd want to know if that happened, because a lot of our code
w integer-based duration properties. Use QDeadlineTimer if
> 'Forever' is a valid value (e.g. timeouts).
Agreed.
Thanks for bringing this up in the mailing list.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Cloud Software Architect - Intel DCAI C
On Monday, 23 January 2023 07:07:06 PST Kai Köhne via Development wrote:
> We also don't allow upgrading individual Qt modules, for instance.
qtwebengine being the exception, but indeed.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Cloud Software Architect - Intel DCAI Cl
On Tuesday, 17 January 2023 14:07:42 PST Thiago Macieira wrote:
> The reason is that it is failing to parse a constant expression.
>
> VS2019 is still supported by MSFT in "Mainstream" mode and will be for over
> a year from today:
> https://learn.microsoft.com/en-us/v
ostly do not have translations set up)
Would be good, yes.
> - Do we use std::as_const to avoid detaching containers in loops (mostly
> missing for code ported from Q_FOREACH)
Yes, that's good practice.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Cloud Software Architect - Inte
th of them?
--
Thiago Macieira - thiago.macieira (AT) intel.com
Cloud Software Architect - Intel DCAI Cloud Engineering
smime.p7s
Description: S/MIME cryptographic signature
___
Development mailing list
Development@qt-project.org
https://lists.qt-p
're underutilising your cluster.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Cloud Software Architect - Intel DCAI Cloud Engineering
smime.p7s
Description: S/MIME cryptographic signature
___
Development mailing list
Development@qt-project.org
ht
lld. I've just tested:
$ gcc -fuse-ld=lld -xc /dev/null
ld.lld: error: undefined symbol: main
>>> referenced by start.S:103 (../sysdeps/x86_64/start.S:103)
>>> /usr/lib64/gcc/x86_64-generic-linux/12/../../../../lib64/
Scrt1.o:(_start)
collect2: error: ld returned 1 exi
ess to a cluster. But if you're doing an incremental build while
developing, they're not. Adding it to COIN implies that everyone is
responsible for keeping them working.
But it's for a good reason.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Cloud Software Architect - Intel DCAI Cl
. What do you
> think?
I was going to object to it being in COIN, but considering it may improve
build times in the CI, especially for constrained platforms (like macOS), I
withdraw my objection before I even make it. I think this effort is worth it.
--
Thiago Macieira - thiago.macieira (A
an ODR violation.
static inline in C is closer to C++'s inline. It's the same as C++'s static
inline, actually. Which means that any out-of-line copies that were emitted
will not be merged by the linker.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Cloud Software Architect - Intel DCAI
exactly the one that
was intended (read: the tag wasn't deleted and recreated).
--
Thiago Macieira - thiago.macieira (AT) intel.com
Cloud Software Architect - Intel DCAI Cloud Engineering
smime.p7s
Description: S/MIME cryptographic signature
___
Developme
On Friday, 13 January 2023 06:12:44 PST Samuli Piippo via Development wrote:
> bitbake runs branch validation as 'git branch --contains --list
> '
Then don't do *branch* validation. I'm sure it can validate tags too.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Cloud So
t explain anything. I understand it verifies
the content, but what does that mechanism have to do with using tags? Tags are
just as verifiable as branches. In fact, they're more verifiable than branches.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Cloud Software Architect - Intel D
On Thursday, 12 January 2023 07:54:33 PST Jon Trulson wrote:
> The reason this became a problem for me was that meta-qt5's warrior
> branch uses these Qt branches (5.12.12 in my case), and these builds now
> fail.
They should use the tags, not the branches.
--
Thiago Macieira - thiago
On Thursday, 12 January 2023 00:24:16 PST Christian Kandeler via Development
wrote:
> On 1/12/23 01:24, Thiago Macieira wrote:
> > On Wednesday, 11 January 2023 15:29:11 PST Jon Trulson wrote:
> >> Will these be returning at some point?
> >
> > No.
>
&
On Wednesday, 11 January 2023 15:29:11 PST Jon Trulson wrote:
> Will these be returning at some point?
No.
Use the tag instead.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Cloud Software Architect - Intel DCAI Cloud Engineer
n that list.
I preferred the less intrusive older UI, but I can work with this.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Cloud Software Architect - Intel DCAI Cloud Engineering
___
Development mailing list
Development@qt-project.org
htt
ed to be in a special lab with no direct Internet
access, which means they couldn't be part of a CI.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Cloud Software Architect - Intel DCAI Cloud Engineering
___
Development mailing list
Develop
hich about doubles the HW need.
And given that Mac Pros are continuing with Intel Xeon line for the
foreseeable future, you can't turn off x86 testing or for binary products.
I wonder what will happen in a few years, when the last generation of Intel
Mac Minis stop working due to old age.
-
cores of the same Xeon generation. The top of the line model with 28 cores is
roughly the same price as an workstation or full server with two 28-core Xeon
Gold, or servers with two 32-core Xeons of the generation after that with a
slightly lower base clock.
--
Thiago Macieira - thiago.maciei
e point is that we
need to officially drop the platform first, before we can depend on and require
some of those APIs. It's not the other way around.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Cloud Software Architect - Intel DCAI Cloud Engineering
___
osoft skipped Windows 9, that
unfortunately makes too much sense.
if (winVerStr.startsWith("Win9"))
return Windows95;
--
Thiago Macieira - thiago.macieira (AT) intel.com
Cloud Software Architect - Intel DCAI Cloud Engineering
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
Mac Desktop open-source
> development, please
> consider keeping Mac OS 10.15 as a target.
If you convince Apple to restart support for it, sure.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Cloud Software Architect - Intel DCAI
hould ensure everything passes
before you make the configuration enforced.
Changing how one of our binaries will get released is a different story, but
that's not what you're asking.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Cloud Software Architect
no objections. It's a single
function with possible security implications. I'd like to have it.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Cloud Software Architect - Intel DCAI Cloud Engineering
___
Development mailing list
Development@q
E, also view
> all unit tests there, debug, fix, build and run selected directly and so on?
Yes, start by configuring each module with cmake (or configure, in case of
qtbase), not the top-level.
You can't build them all at once if you do this. You'll need to configure and
build each one.
--
whether this support shall
remain, in particular as Qt 6.5 should be a Commercial LTS, so 6.6 is a good
point for dropping some compatibility.
Jörg, Tor Arne, Alexandru, Kai, Alexey, anything I forgot?
--
Thiago Macieira - thiago.macieira (AT) intel.com
Cloud Software Architect - Intel DCAI
On Thursday, 24 November 2022 02:04:49 PST Edward Welbourne via Development
wrote:
> Thiago Macieira (23 November 2022 22:11) wrote:
> >> I'll fix it.
> >
> > That was easy. I just had to remove code to make it work.
>
> Always a satisfying solution to a problem
On Wednesday, 23 November 2022 11:55:01 PST Thiago Macieira wrote:
> abstractpickingjob.cpp:74:33: error: cannot convert ‘const Matrix4x4’ {aka
> ‘const Qt3DCore::Matrix4x4_SSE’} to ‘const Qt3DCore::Matrix4x4_AVX2&’
>
> I'll fix it.
That was easy. I just had to remove code to mak
On Tuesday, 22 November 2022 07:10:28 PST Thiago Macieira wrote:
> > Are the changes that enable multi subarch builds already up?
> > I did not manage the find them.
>
> Not yet, only the initial clean-ups. I want to get them working first. I
> fixed the qml_register_types is
one)".
So I've closed the issue because there's nothing we have to do or even can do.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Cloud Software Architect - Intel DCAI Cloud Engineering
___
Development mailing list
Development@qt-p
On Tuesday, 22 November 2022 04:35:35 PST Joerg Bornemann via Development
wrote:
> On 11/21/22 03:38, Thiago Macieira wrote:
> > I've just finished a qtbase build on Linux with two sub-architectures and
> > the symbol comparison of all the resulting libraries has shown zero
On Sunday, 20 November 2022 18:38:08 PST Thiago Macieira wrote:
> I've just finished a qtbase build on Linux with two sub-architectures and
> the symbol comparison of all the resulting libraries has shown zero
> difference..
Done. All modules now built in multi-subarch mode. I've submit
ccess the first patch. The other two links show "Not found".
My bad, the last two should be '58 and '59. I did the lazy trick of pasting
the same URL three times and updating the last digit, but didn't notice that
they were off by 20.
--
Thiago Macieira - thiago.macieira (AT) intel.com
C
On Thursday, 17 November 2022 10:56:22 PST Thiago Macieira wrote:
> The algorithms available are:
> * baseline SSE2: no comparisons
I realised yesterday that, since there will be no benchmarking to prove that
the new SSE2 code is better than the old one, it is by definition ready. So
On Friday, 18 November 2022 09:05:51 PST Thiago Macieira wrote:
> 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 the existing QBlue
On Friday, 18 November 2022 04:16:48 PST Shawn Rutledge via Development wrote:
> On 2022 Nov 18, at 03:13, Thiago Macieira
> mailto:thiago.macie...@intel.com>> wrote:
> > I was working on extended integers and added qint128 and quint128 to
> > qglobal.h
> Inte
make some experiments.
> Are you planning to introduce q{u}int128 for 6.5 or for 6.6?
I'll wait for 6.6.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Cloud Software Architect - Intel DCAI Cloud Engineering
___
Development mailing lis
build, add a removed_api.cpp that also #undef
__SIZEOF_INT128__
It might be a good idea to move that backup definition to QtCore, so
QtBluetooth isn't depending on just how qtypes.h does it.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Cloud Software Architect - Intel DCAI Cloud
ase/+/386952
See the search at
https://codereview.qt-project.org/q/
is:open+owner:thiago.macieira%2540intel.com+message:QString
The changes are mostly organised as "reorganise the pre-AVX code", then
"rewrite AVX2 code" then "add AVX512VL code" for each of th
he
performance on both the Golden Cove P-core and the Gracemont E-core, but the
thing runs Windows and the IT-mandated virus scans, so I will not bother.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Cloud Software Architect - Intel DCAI Cloud Engineering
___
doing.
>
> I hear you, but I'm not ready to give in just yet.
Nor am I.
Though I am postponing the QString vectorisation update to 6.6 because I don't
have time to collect the benchmarks to prove I'm right before feature freeze
next Friday.
--
Thiago Macieira - thiago.macieira (AT) in
than that and can continue to
speculatively run past the atomic operation, so long as the behaviour is as-is
to not having done so.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Cloud Software Architect - Intel DCAI Cloud Engineering
___
De
ou and I do to optimise these things
matter, in the end. We may save 0.5% of the CPU time, only for that to be
dwarfed by whatever QtGui, QtQml are doing.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Cloud Software Architect - Intel DCAI Cloud Engineering
__
user
isn't affected). Because you pointed to QStringTokenizer and that implicitly-
copies a QString.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Cloud Software Architect - Intel DCAI Cloud Engineering
___
Development mailing list
D
-old Sandy Bridge, 19 on Haswell, 18 on everything since Skylake.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Cloud Software Architect - Intel DCAI Cloud Engineering
___
Development mailing list
Development@qt-project.org
https://lists.qt
change that we do.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Cloud Software Architect - Intel DCAI Cloud Engineering
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
n remains:
> We've found a robust solution to this problem via the removed_api
> mechanism, which is going to keep the QString overload, but hide it from
> clients. (At least, I *think*.) This will make calls passing u""
> literals to keep working just fine. So what other conce
egularExpressionMatch, so that the solution is thread-safe. This is
neither simple to understand, to code, or to port existing code over to. It
also requires copying the data over (hopefully, implicitly) to the proxy
object, so it doesn't solve anything.
--
Thiago Macieira - thiago.macieira (AT) i
t code is going to store anyway.
I don't think we will ever change return types.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Cloud Software Architect - Intel DCAI Cloud Engineering
___
Development mailing list
Development@qt-project.org
h
eet: if they do that, we ban the ENTIRE header
for that implementation, thus concluding that this implementation HAS NO
C++23 feature implemented.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Cloud Software Architect - Intel DCAI Cl
On Thursday, 10 November 2022 10:40:35 PST Giuseppe D'Angelo via Development
wrote:
> On 09/11/2022 20:25, Thiago Macieira wrote:
> > Our API should default to passing QStrings for simplicity and not to
> > confuse>
> > the user. The fact that I cannot wrote:
> >
On Wednesday, 9 November 2022 11:25:32 PST Thiago Macieira wrote:
> On Wednesday, 9 November 2022 02:52:15 PST Marc Mutz via Development wrote:
> > We can also return spans:
> > QSpan actions() const;
>
> we CANNOT and MUST NOT.
Unless you can find a way to return the co
licity and not to confuse
the user. The fact that I cannot wrote:
foo(u"bar');
if foo takes a QString is MESSED UP.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Cloud Software Architect - Intel DCAI Cloud Engineering
___
Development m
On Wednesday, 9 November 2022 02:52:15 PST Marc Mutz via Development wrote:
> We can also return spans:
>
> QSpan actions() const;
we CANNOT and MUST NOT.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Cloud Software Architect - Intel DCAI Cloud En
201 - 300 of 6027 matches
Mail list logo
