On Tuesday, 19 November 2019 00:23:52 CET Thiago Macieira wrote:
> I wasn't referring to QTextCodec.
>
> I was referring to these files:
Sorry, race condition. The Ctrl for Ctrl+F1 was pressed too early and matched
the Enter for the next line causing Ctrl+Enter (Send).
$ ls
interface to register new codecs, provide UTF-* directly,
> and let the "fancy" ones live on in a seperate module, plugging them in at
> runtime.
I wasn't referring to QTextCodec.
I was referring to these files:
--
Thiago Macieira - thiago.macieira (AT) intel.com
On Monday, 18 November 2019 17:05:29 CET Lars Knoll wrote:
> > On 18 Nov 2019, at 17:00, Kevin Kofler wrote:
> >
> > Thiago Macieira wrote:
> >
> >> The codecs we want to remove are just big tables of mapping old, legacy
> >> codecs to UTF-16. We can
ly a Qt 6 one, will be
run with no locale set. So if the locale isn't set to UTF-8, then it's
explicit. The question is whether it was *intentional* to change the codec.
As I've argued time and again, changing the locale to English is standard
practice in any tool parsing another tool's output. But did they mean to
change the codec too?
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel System Software Products
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
)
Given that Fedora 31 is current, Fedora 24 is 3 years old. It's probably old
enough.
And Python sets LANG to it if the environment is unset.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel System Software Products
string() produces output and we'll live with the
danger that some code does our choice. My search through Linux library code
found no instance of a permanent setlocale() call with a non-null second
parameter (Qt is actually the only exception).
I hope this clarifies things and we&
odecs we kept and only use ICU, then QTextCodec will have
negligible cost and could stay in QtCore.
If it stays in QtCore, we still have a question whether QString::fromLocal8Bit
shall assume it's UTF-8 on Unix systems.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Archite
8 in QString::fromLocal8Bit.
If we say that QString::fromLocal8Bit is UTF-8 on Unix, then either:
a) we fix the environment when the locale says it isn't UTF-8
b) we refuse to run when it isn't UTF-8
c) we pretend it's UTF-8 and potentially produce and consume mojibake
>
Just remove it. Make it work with the current settings, despite there being a
better way.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel System Software Products
___
Development mailing list
Development@qt
e a check for
assumption:
if (locale is not UTF-8)
qFatal("Qt only supports UTF-8 locales. "
"Please configure your system properly");
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel System Software Products
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
ronous API definitely needs
deprecation.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel System Software Products
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
Qt to
> this.
>
> Intuitively, it seems that port qt to a non-posix system can be a
> titanic task, but at least I want to evaluate the manpower for this.
Yes, don't go there. The only non-POSIX system supported is Windows.
--
Thiago Macieira - thiago.macieira (AT) intel.com
So
On Monday, 4 November 2019 10:55:03 PST Thiago Macieira wrote:
> I'll do a full search on Clear Linux to see if there's any software that
> checks the return value of setlocale().
All "setlocale" calls.
First, the calls that to strcmp: I found comparisons in gn
On Monday, 4 November 2019 11:50:01 PST André Pönitz wrote:
> On Mon, Nov 04, 2019 at 11:38:07AM -0800, Thiago Macieira wrote:
> > On Monday, 4 November 2019 11:18:12 PST André Pönitz wrote:
> > > A parser accepting the output of one might or might not be able to
>
On Monday, 4 November 2019 11:18:12 PST André Pönitz wrote:
> A parser accepting the output of one might or might not be able to
> handle the second.
A driver would set LC_ALL in the environment when it calls gcc.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect -
be non-configurable).
I don't disagree on the statement. I just disagree on whether it's harmful.
*Not* calling qputenv could be harmful too.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel System Software Products
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
ior value.
That only applies to QProcess. It will not apply to third-party components
that fork helper processes.
It's possible atfork() could do this, but I'm not sure. it won't catch all of
them, especially those that prepare the environment before forking (like
execve
to setlocale(LC_ALL, "").
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel System Software Products
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
e to
suppress the Qt's override not sufficient?
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel System Software Products
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
ot open ??.qm: No such file "..., 45Cannot open ??.qm: No such
file or directory
> > How about making the resetting opt-out, instead of opt-in?
> > QT_NO_OVERRIDE_LC_CTYPE?
>
> I was more thinking of a runtime option. Like
>
> QCoreApplication::setPropagateOurChoice
imple one-liner opt-in for applications that
> want to engage in "strict parenting" might be an option, too.
How about making the resetting opt-out, instead of opt-in?
QT_NO_OVERRIDE_LC_CTYPE?
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel System Software Products
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
can call setlocale() after QCoreApplication has. It's possible that they,
unknowingly, override our choices and change the C library back to an
incorrect state. If we do set the environment, this cannot happen.
Another side-effect is that in a Qt-based graphical
hich LTS we had said we were going to do it for.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel System Software Products
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
ing to release from the 5.12 branch directly, since the rate of
change is small enough?
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel System Software Products
___
Development mailing list
Development@qt-proje
from other people, like
backtraces, or just plain looking at past history via git show and git blame.
You *have* to deal with the original.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel System Software Products
On Thursday, 17 October 2019 23:02:06 PDT Kai Pastor, DG0YT wrote:
> char *const key vs. char* const key
Third option:
char * const key;
I've seen all three in Qt source, though I think your first one is the one
that strictly follows our coding style guidelines.
--
Thiago
ttps://github.com/fmtlib/fmt is MIT-licensed. If we can leverage the
implementation, it's a path forward.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel System Software Products
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
est this can happen in C++23, lLet's table this discussion
until 2028.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel System Software Products
___
Development mailing list
Development@qt-project.org
https://
PL-2.0 MPL-2.0-no-
copyleft-exception NCSA NTP OFL-1.1 OpenSSL Public-Domain SGI-B-2.0 Unlicense
Zlib bzip2-1.0.6
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel System Software Products
___
Development mailing li
pen
source and there's no cannibalisation.
From a non-open point of view, that's not my place to comment. I firmly
believe in "why you should licence your next library GPL".
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel System Software P
On Monday, 30 September 2019 11:06:18 PDT Matthew Woehlke wrote:
> IOW, the example would look like:
>
>
> fullname.setBinding(
> [](Foo const* self){
> return self->surname() + " " + self->lastname();
> });
How does the QProperty class
les the fonts *again* so I get huge screens. So I'm
setting for readable GTK text with tiny icons.
Firefox seems to work fine and has right-sized icons. Google Chrome is scaled
to 225%.
> If this logic could be contained within the XCB platform plugin, and the
> result reported to
ct to (say, a projector in a conference
room)? Does it:
a) keep the physical one from the monitor?
b) use 96x96?
c) use one of the other monitor's settings?
(hint: a, b and c are wrong)
Right now, I need exactly two values: the display panel's multiplicative
factor of 2 and the
ue_ptr deleters, not like QScopedPointer's deleter.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel System Software Products
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.o
scale
> >>>> factor.
>
> On Thursday, 26 September 2019 04:48:26 CEST Thiago Macieira wrote:
> >>> Sure, but where, on X11?
>
> On Thursday, 26 September 2019 00:08:34 PDT Allan Sandfeld Jensen wrote:
> >> xrandr?
>
> Thiago Macieira (26 Septe
e);
const QProperty &firstName() const;
private:
QProperty m_firstName;
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel System Software Products
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
On Thursday, 26 September 2019 00:08:34 PDT Allan Sandfeld Jensen wrote:
> On Thursday, 26 September 2019 04:48:26 CEST Thiago Macieira wrote:
> > > If possible, I’d like us to move away from relying on setting
> > > environment
> > > variables, and/or switch to spe
s your warranty :-)
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel System Software Products
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
On Wednesday, 25 September 2019 11:08:39 PDT Elvis Stansvik wrote:
> Large parts of the world did not grow up with inches. I know I'd have
> a hard time to hold up my fingers to show an inch...
For most people, "DPI" is an arbitrary number ranging from 72 to 288...
tion
for X11 then: continue using the variables as they are.
> If possible, I’d like us to move away from relying on setting environment
> variables, and/or switch to specifying per-screen DPI instead of a scale
> factor.
Sure, but where, on X11?
--
Thiago Macieira
hat function above? Assume there's less than 0.1% of them doing that.
Anyway, what's the correct way to specify now that one of my external monitors
is highdpi but the other isn't?
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect
that allow us to quickly get all the output from those classes and see if
there's something unexpected, compared to other tools and system
configuration.
Ditto for highdpi.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Sys
On Thursday, 19 September 2019 03:17:12 PDT Giuseppe D'Angelo via Development
wrote:
> On 18/09/2019 17:33, Thiago Macieira wrote:
> >>> We've never required C++11 Standard Library. We've only required the
> >>> core
> >>> languag
ied for
performance and shortcomings and we can even submit fixes if we feel like it.
EXCEPT for Integrity.
[*] Note the blog author's initials :-)
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel System Software Products
__
rom dropping features or an entire
platform.
Still, it's a decision we can make. I'm not opposed to it, as I have been
bitten by Integrity's compiler shortcomings before (see QRandomGenerator's
integration log). But it's a *decision* to *change* our policy.
--
T
On Thursday, 19 September 2019 06:23:26 PDT Giuseppe D'Angelo via Development
wrote:
> On 18/09/2019 01:37, Thiago Macieira wrote:
> > Marc's proposal is that we should accept that these things are rare and
> > simply correct when they do happen. Since our code is test
rds in C++14 and C++17
so they got new numbers (I think the "relaxed constexpr" is one such). But you
should know you're targetting that particular feature and thus that it had a
different number than the baseline.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Ar
7;
> > from where it is then went in Qt 5.13.0 and future releases
> If you want to see where the patch is currently available just click on
> the review ( https://codereview.qt-project.org/c/qt/qtbase/+/259142 )
> and then on 'Included In'.
There's a bot now that
eems like it. Like I said, we've never required the C++11 standard library
and we need to be sure the feature we need is supported before we commit to
it.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel System Software Products
__
; So, is the CI just using a totally outdated toolchain?
More than likely we're just missing an -l flag or equivalent to link to the
necessary implementation. If that's the case, it's no different than libstdc++
which requires adding -lpthread to your link command-line.
--
Th
r comes out with the feature, we may get compilation errors.
Our users understand that we cannot test things that don't exist, so older
versions can fail to compile on new compilers (or produce a lot of warnings).
Issuing fixes is enough.
--
Thiago Macieira - thiago.macieira (AT)
those I listed. Let's not do it again without
strong reason.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel System Software Products
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
:
> enables devicePixelRatio scaling in QtGui; applies per-screen scale factors
> computed from on screen DPI. - QT_FONT_DPI [now x-platform] : overrides
> the DPI for all screens
What happened to QT_AUTO_SCREEN_SCALE_FACTOR and QT_SCREEN_SCALE_FACTORS?
--
Thiago Macieira - thiago.macieira (AT)
On Monday, 9 September 2019 14:07:59 PDT Lisandro Damián Nicanor Pérez Meyer
wrote:
> Is this acceptable? I really think it is not, but...
It's not. Requiring people to build LLVM + Clang, whcih is huge, is not
something we should do.
Please work around.
--
Thiago Macieira - thiago.
ing SD-1 was easy, but now that it's been incorporated
into the language it may no longer be.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel System Software Products
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
On Friday, 6 September 2019 09:39:32 PDT Edward Welbourne wrote:
> Thiago Macieira (6 September 2019 16:58)
>
> > I also don't understand what we need to reduce. Having the current stable,
> > current post-feature-freeze and the current in-development branches have
> &
Qt::horizontal,
> Qt::vertical, Qt::[color name], Qt::SHIFT, Qt::Monday, Qt::XAxis.
>
> Option C does not work, a namespace is either entirely inline or it's not.
Option D: the inline namespace gets another name, something different from
"Qt".
Suggestion: Qt6
--
darkGreen,
darkBlue,
darkCyan,
darkMagenta,
darkYellow,
transparent
};
}
}
Or are you proposing that all those enumerations be accessible without
namespace specification?
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Archit
w thing is the Qt 6 branch ("dev"), which
does not need frequent merging.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel System Software Products
___
Development mailing list
Development@qt-project.org
h
ase it and 5.13 gets merged into 5.14.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel System Software Products
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
ant to those who are deploying 5.13.x.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel System Software Products
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
is profile-guided optimisation. Compile Qt
with instrumentation, run some complex but representative applications, then
feed the profile results back into GCC. That way, it will organise the code to
optimise I-Cache usage and move actually unlikely code as well as only-used-
once code to sepa
ian used
KOI8-R)
Anyway, doing a memory wipe. Aside from ISO-8859-1, I don't want to think of
any of the others for another 15 years.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel System Software Products
_
04\231\307\275"
$ LC_ALL=pt_BR ls doesntexist
ls: cannot access 'doesntexist': Arquivo ou diret�rio inexistente
$ LC_ALL=el_GR ls doesntexist
ls: cannot access 'doesntexist': ��� ��� �� �� � �
$ LC_ALL=el_GR.UTF-8 ls doesntexist
ls: cannot access 'doesntexist': Δεν υπάρχει τέτοιο αρχείο ή κατάλογος
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel System Software Products
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
g to
> anything as far as I can tell. There’s no -finput-charset=utf-8 anywhere in
> Qt’s sources. That implies that gcc will try to pick up the input charset
> from the locale.
GCC and Clang default to UTF-8 *unless* you pass -finput-charset to something
different, independent of what yo
static
builds.
Ugh... in static builds there *is* no DLL.
Ok, that seems like a worthwhile objective.
> (I did not know about this leak before reading your earlier message. I
> thought we had cleanup in place like for Unix. But I verified and indeed,
> it seems that we do not have thread
ded libgcc does not need pthread emulation
4. concluded that anyone using pthread emulation was Cygwin
Conclusion #3 is correct. Conclusion #4 wasn't, because I failed to take into
consideration that the pthread emulation may be needed for other features
which Qt doesn't need (namely, s
age, they can change
the thread start too.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel System Software Products
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
On Friday, 23 August 2019 11:16:29 PDT Thiago Macieira wrote:
> Simon wrote:
> > I ran into the crash a while ago in the CI. See also
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83562 .
>
> That bug report shows that GCC does not properly implement thread_local on
> M
On Saturday, 24 August 2019 02:21:13 PDT Konstantin Tokarev wrote:
> 23.08.2019, 21:11, "Thiago Macieira" :
> > On Friday, 23 August 2019 09:04:55 PDT Konstantin Tokarev wrote:
> >> > libgcc on pure MinGW doesn't use winpthreads, it uses Win32.
> >>
ow that it uses the native TLS support.
In any case, we don't need that full toolchain, since we don't need the LLVM
tools. We can work with GNU binutils just fine with Clang.
--
Thiago Macieira - thiago.macieira (AT) intel.
it. 32-bit Windows GCC-compatible-ABI
support would be provided by Clang.
If this proposal seems acceptable, we need to see if it is technically
feasible: can Clang/MinGW compile our codebase? And how does one go about
installing it?
--
Thiago Macieira - thiago.macieira (AT) intel.com
So
ead in Qt, so why are you telling us this?
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel System Software Products
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
On Friday, 23 August 2019 08:58:09 PDT Simon Hausmann wrote:
> Hi,
>
> I ran into the crash a while ago in the CI. See also
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83562 .
That last comment in the bug report seems relevant to us.
--
Thiago Macieira - thiago.macieira (A
ause it's
> pthread_cond and that needs pthread_mutex?
Yes. The problem is that QMutex was made to use a futex or something similar
in all platforms, which means QWC is way more expensive.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel System
_THREAD_LOCAL. If that causes GCC-built MinGW
applications to crash on exit, then we stop using GCC and switch to Clang.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel System Software Products
___
Development mailing lis
e that and all of Qt's modules build like that.
We just haven't forced that choice on our users. It's opt-in for them.
But we can use u"" just fine, right now.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel System Software Products
_
On Thursday, 22 August 2019 14:41:51 PDT Matthew Woehlke wrote:
> On 22/08/2019 17.00, Thiago Macieira wrote:
> > For Qt 6, it is possible (and is still my goal[*]) to make creating a
> > QString out of a QStringView and through it from a u"" literal happen
> > in
o type "\u00DF" and "\u00E9", I opened kcharselect, typed the characters that
I already knew I wanted and searched.
PPS: I can type "ę", "°", "ª", "€", "£", "¥", &qu
content of the string.
For Qt 6, that won't be needed, but we won't need an UDL either.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel System Software Products
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
of such is a pair:
{ m_size: N, m_data: PTR }
a QString created from this QStringView would be:
{ m_size: N, m_data: PTR, d: nullptr }
[*] Unless we decide that QString always points to heap memory to avoid the
plugin-unloading issue.
--
Thiago Macieira - thiago.macieira (AT) int
we'll just remove the platform from the rotation
until they properly implement C++11 thraed_local.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel System Software Products
___
Development mailing list
Development@qt-pr
The 16.0 update to MSVC 2017 has already been released, but got a new name:
MSVC 2019.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel System Software Products
___
Development mailing list
Development@qt-project.
first US-ASCII scanning backwards from the
end]
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel System Software Products
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
assessment of what the C++20 changes mean for u8"" first,
since it changes from char[] literal to char8_t[] literal. Adding the
overloads to QString is easy, but we may have places that take a const char*,
put it in a variable, then pass to a QString. Those will need updating.
-
ven though it looks like GCC 7 would be enough, maybe
> even an earlier version).
Since GCC 7 is working, we can require GCC 7 for MinGW for 5.15, hopefully
5.14 so I can begin ressurrecting the Q_THREAD_LOCAL patches.
Can we do that?
--
Thiago Macieira - thiago.macieira (AT) intel.com
So
//docs.microsoft.com/en-us/visualstudio/releasenotes/vs2017-relnotes-v15.7
says it had fixed the bug, but didn't. As of 15.9 it was still there, so
the fix is in the version after that: 16.0.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel
If that's what was meant, I'm
all for it. After the upgrade I've just run, I have GCC 9.2, which is great.
But I had understood the proposal as linking to MSYS2 libraries.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - I
the -static-runtime option to configure does
(additional to -static).
Note: DO NOT use -static with MSVC 2017.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel System Software Products
___
Development mailing
On Wednesday, 21 August 2019 12:54:11 PDT Thiago Macieira wrote:
> MSYS2 is Cygwin-like. It tries to emulate a Unix on Windows. It's great for
> porting Unix software to Windows and I love that it gives me a bash and
> pacman for when I need to develop on Windows. But it's emula
d pacman
for when I need to develop on Windows. But it's emulation, like:
https://github.com/Alexpux/Cygwin/blob/master/winsup/cygwin/fork.cc
Native Windows software, which Qt on Windows is, shouldn't use that. MinGW is
supposed to be *actual* Windows.
--
Thiago Macieira - thiago.macie
On Wednesday, 21 August 2019 11:35:37 PDT Mathias Hasselmann wrote:
> Am 21.08.2019 um 19:38 schrieb Thiago Macieira:
> > PPS: can we drop MinGW support in Qt 6?
>
> What alternative do you propse?
Clang/MinGW. However, after a quick test, turns out that this code only
compi
going to possibly crash the same way that
QStringLiteral today does.
PS: this is also why we can't use thread_local in Qt 6 just yet. MinGW does
not support those with non-trivial destructors.
PPS: can we drop MinGW support in Qt 6?
--
Thiago Macieira - thiago.macieira (AT) intel.com
building a plugin?
All macOS plugins or just *our* plugins? QPluginLoader doesn't unload, but
QLibrary does.
We can force a plugin not to allow unloading, with the -z nodelete linker
flag. Works on ELF systems, I don't know about Mach-O.
--
Thiago Macieira - thiago.macieira (AT
On Wednesday, 21 August 2019 09:19:26 PDT Konstantin Tokarev wrote:
> 21.08.2019, 19:02, "Thiago Macieira" :
> > On Wednesday, 21 August 2019 08:23:27 PDT Konstantin Tokarev wrote:
> >> I hope that standard committee will never introduce implicit generation
> &g
iewV2NG
is that worse than Creator showing in yellow that "warning: comparison of
integers of different signs: unsigned long and int" ?
Or "macro name is a reserved identifier" in
#define _GNU_SOURCE
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Archi
On Wednesday, 21 August 2019 08:23:27 PDT Konstantin Tokarev wrote:
> I hope that standard committee will never introduce implicit generation of
> UTF16 literals from C string literals.
You're over 10 years too late. That's exactly what u"" does.
--
Thiago Maci
And if we know that it's always
heap storage, we can also simplify our memory management code by not having
immutable d-pointers either.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel System Software Products
___
ie
> u8”foo” without the explicitness?
We can and already do that. But that's not optimal, since the UTF-8 algorithm
has a cost.
That's why we are not removing QLatin1String: the Latin1 algorithm is as fast
as memcpy. The only thing better than that is zero copies.
--
Thiago Maciei
On Wednesday, 21 August 2019 07:47:23 PDT Thiago Macieira wrote:
> On Wednesday, 21 August 2019 03:01:29 PDT Tor Arne Vestbø wrote:
> > This should just be test[“key”] = “value”. How do we get there?
>
> Do you mean "make this the most optimal?" If so, then we don't
1001 - 1100 of 6749 matches
Mail list logo
