's the non-UB solution?
--
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
problem is the copy or move, since now the object's
this no longer points to the dummy member inside the QObject-derived class,
but to somewhere on the stack. Then that UB pointer manipulation begins
reading garbage and making matters go from bad to worse.
--
Thiago Macieira - thiago.m
On Wednesday, 15 July 2020 13:20:33 PDT Thiago Macieira wrote:
> In addition, I'd like someone to explain here:
[snip]
5) How you're going to fix the UB in the code generated by moc. This requires
a satisfactory answer of C++17 or C++2a strictly compliant code, or we'll have
On Friday, 17 July 2020 09:56:39 PDT Giuseppe D'Angelo via Development wrote:
> Il 17/07/20 17:30, Thiago Macieira ha scritto:
> > I will give a +2 for this patch, since I prefer it. That means adding
> > properties doesn't imply an extra 8 bytes per class in the hier
operties in the d
> > pointer, but users don't usually have d pointers]
>
>
> Not sure what you mean here. This is only about our Q_PRIVATE_QPROPERTY, not
> about the QProperty class.
Oh, right, never mind.
Ulf, please add this to the Coding Style:
Every public class w
office and ask who's running
anything older.
--
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
perty is a different thing than converting old
> APIs in a compatible way.
The complexity behind the scenes for us to support it is our problem, users
shouldn't care.
They will only care that the code they write is the same, regardless of
whether it's an old or a new class.
--
value = action->text;
would be different things. Not to mention QString builder failures. People
should always write action->text().
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel System Software Products
___
D
>
QIODevice -> QObject. If each class has properties, that adds 40 bytes to the
full size of QSctpSocket.
[Yes, I know Qt-based classes should just put their properties in the d
pointer, but users don't usually have d pointers]
--
Thiago Maci
ps://godbolt.org/z/nhex5x
--
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
added this support, because it can't
work. The commit will need to be reverted.
--
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
anks for the clarification.
Sent a post-commit -2 to the commit that added [[no_unique_address]]. We need
a thorough review of this feature.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel System Software Products
__
n d->title.
>
>
> The structMemberFunctions are different for each property, but that doesn't
> increase the size of QAction instances.
>
> The relevant macros are defined in qtmetamacros.h.
In other words, action->text and action->title aren't the same
ot;.
action->text = "foo";
action->title = "bar";
Since std::is_same_vtext), decltype(action->title)> and
&action->text == &action->title, how does the code above even work?
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Archit
.
Hmm... design question then: if the address isn't relevant and the data inside
isn't relevant either (because it can't be), why do we need a member in the
first place? What information does it convey that is neither the address nor
the contents?
--
Thiago Macieira - thiago
existing class in Qt 6.0.
Modulo wholesale module exceptions like QtWidgets.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel System Software Products
___
Development mailing list
Development@qt-project.org
https://list
t; do so, is surely a good first step - we can polish it later !
The problem is that I can't review the changes and say they are correct if I
don't know what correct is.
That's why I am calling for some more information for those outside the
initial development team.
--
Thiago Mac
et moc know of the new storage
type. So anyone using QMetaObject and QObject::property/setProperty should not
be affected.
But that needs to be described in the coding guide.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel System Software Products
cial. For example, QWidget has 59 properties not
including QObject's, but including the computed ones. Does that mean we're
adding 59*8 = 472 bytes to 536-byte QWidgetPrivate, an 88% increase? [Note:
size already includes QString, QList and QByteArray's expansion to 24 bytes
0-pre-alpha-released
> - https://wiki.qt.io/Online_Installer_4.x
>
> Bonus:
>
> - https://pastebin.com/jUN51zci
>
> Maybe you wanna give it a try and let us know how well it works?
Will take a look, thanks.
--
Thiago Macieira - thiago.macieira (AT) intel.com
On Monday, 17 February 2020 12:07:42 PDT Thiago Macieira wrote:
> The install script is used by many deployment systems and Tino said that
> unattended installation would become even easier. We're still waiting for
> details, though.
>
> The problem is *downloading* the in
On Wednesday, 1 July 2020 14:21:33 PDT Thiago Macieira wrote:
> Re: https://bugreports.qt.io/browse/QTBUG-84739
> Summary: Qt 5.15 has an unintentional change in behaviour that has broken
> existing applications. We need to decide whether to:
> b) revert permanently
Looks like the di
On Thursday, 9 July 2020 03:48:18 PDT Lars Knoll wrote:
> The easiest fix for this would probably be to simply change the "QList
> glyph_indices;" in QFontSubset to a QSet.
That would make the output non-deterministic. If determinism is wanted, a
sorted container is prefera
may fail in part due to the fact that the CMap object reflects the order in
> which the characters appear in the text. This would be the case for PDF
> documents generated using Qt.
I see. Thanks, this explanation above should be in your commit message.
--
Thiago Macieira - thiago.macie
27;s not clear to me yet, despite reading the links you provided, what the
issue is. When you write your commit, please explain in the commit message
what the issue is and how your changes address them.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect
hello("hello");
QCborValue(hello).toJsonValue();
// "SGVsbG8"
QCborValue(QCborKnownTags::ExpectedBase64, hello).toJsonValue();
// "SGVsbG8="
QCborValue(QCborKnownTags::ExpectedBase16, hello).toJsonalue();
// "48656c6c6f"
--
Thiago Macieir
d look at the list of meta types and explicitly list
how they are converted to CBOR and JSON, so for QByteArray it would be clear
that it's a lossy conversion using fromUtf8. Any type not in the white list
gets converted to JSON null or CBOR undefined but subject to change.
And unit
On Thursday, 2 July 2020 03:57:08 PDT Tor Arne Vestbø wrote:
> Which does not match the documented behavior, so I think a revert makes
> sense to avoid the surprising behavior change.
Thanks for the opinion, Tor Arne. For the record, revert permanently or revert
only in 5.15?
--
On Thursday, 2 July 2020 02:12:32 PDT Mathias Hasselmann wrote:
> Am 01.07.2020 um 23:21 schrieb Thiago Macieira:
> > Re: https://bugreports.qt.io/browse/QTBUG-84739
> > Summary: Qt 5.15 has an unintentional change in behaviour that has broken
> >
> > existing appl
want anything different from what the encoder does, you do it yourself.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel System Software Products
___
Development mailing list
Development@qt-project.org
https://lists.
n field scenario, the new behaviour is quite useful. You don't need
to pre-encode, the converter will do it for you.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel System Software Products
___
Development m
tring() is one of
those cases.
As can be seen in the testcase, the old behaviour is silently lossy, which
means it's dangerous. The new behaviour is surprising, but it's not lossy, as
the original byte data is retrievable:
$ base64 -d <<https://tools.ietf.org/html/rfc7049#section-4.1
--
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 open source releases of this module at all times.
--
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
rename QAnyStringView into the newly liberated name?
--
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/li
until Qt 6.0, I'd like to propose to just replace
> all overload sets that contain QL1S with one overload taking
> QAnyStringView
Agreed for the string classes themselves.
> The implementation usually contains the optimized handling of L1 data
&
to get Q_OBJECT right, because of the need for moc.
Running moc on another library's headers is a big indication that something is
wrong. But I've seen it.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel System Software Products
___
rtual function. But that's not too much to ask, since
Q_OBJECT is already doing that.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel System Software Products
___
Development mailing list
Development@qt-project.o
ALL classes with virtuals must be exported and must
have one non-inline virtual member.
This includes templates.
Corollary: templates with virtual should be avoided at all costs.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel System S
On Sunday, 21 June 2020 08:22:14 PDT Alberto Mardegan wrote:
> On 20/06/20 23:45, Thiago Macieira wrote:
> > No, because it won't catch this:
> >
> > class MyProcess : QProcess
> > {
> > protected:
> > virtual void setupChildProcess();
> > };
erride setupChildProcess() like in the example above, what are you doing
in the function?
--
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 dead for the free
software / open source community.
--
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 Monday, 15 June 2020 09:37:31 PDT Alexandru Croitor wrote:
> Thanks for the feedback. Usually Qt forces usage of the bundled 3rd party
> libs via -qt-libpng flags, etc
And that just goes to show why you shouldn't use those binaries.
--
Thiago Macieira - thiago.macieira (AT
On Wednesday, 10 June 2020 19:46:22 PDT Thiago Macieira wrote:
> On Wednesday, 10 June 2020 13:37:02 PDT Alexandru Croitor wrote:
> > > Ditto for macOS. A multi-arch x86_64 build would be welcome (x86_64 and
> > > x86_64h).
> >
> > I think that would be a new feat
-build action to merge the binaries into fat archives. It
doesn't need to be in CMake.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel System Software Products
___
Development mailing list
Development@qt-project.o
reply to Bogdan. We should not require exact same version. We may need
to require "not newer"
Qt needs to continue supporting older moc-generated code that was compiled
into libraries and applications and ditto for rcc, uic. So there's little
reason why the version of those tools has
ting those tools. Most
should be updated so that they don't.
We don't have to fix this for 6.0.
--
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
h
> qmake. We will revisit the multi-arch approach later.
Can they be merged after building? If so, that might be the long-term
solution.
Ditto for macOS. A multi-arch x86_64 build would be welcome (x86_64 and
x86_64h).
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Archi
moves one full level of bootstrapping.
That will leave us with only moc needing bootstrapping. We can therefore
remove libQt5Bootstrap.a and minimise the amount of work needed to keep the
bootstrap working.
--
Thiago Macieira - thiago.macieira (AT) intel
that workflow will not work anymore.
Strictly speaking, you don't have to build Qt twice. You can use your system's
packaged Qt, or Conan or Homebrew or one of the binary builds from qt.io as
the other. If you don't intend to develop it, you can use the regular, release
builds made by
uppercase and stopped requiring repeating the conditions
in the ENDIF() control words.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel System Software Products
___
Development mailing list
Development@qt-project.
for moc to finish. If
you have a cluster, it means the cluster can't be used until moc has finished,
for that file. But that's only for the first file.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel System Software Products
__
On Thursday, 28 May 2020 02:06:01 PDT Shawn Rutledge wrote:
> > On 2020 May 27, at 17:50, Thiago Macieira
> > wrote:>
> > On Wednesday, 27 May 2020 03:42:19 PDT Oswald Buddenhagen wrote:
> >>> this is not something we can subject our users to.
> >>
>
27;t
have one (a header-only class whose only non-inline methods are the moc-
generated ones). Otherwise, #include your mocs.
That said, we shouldn't enforce this.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Sy
learn). It's just the same thing written differently.
[∞] ⎡ 0 1⎤=[8]
⎣-1 0⎦
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel System Software Products
___
Development mailing list
Development@qt-project.org
https
On Tuesday, 26 May 2020 09:17:05 PDT Edward Welbourne wrote:
> (Matrix multiplication isn't commutative.)
This more or less summarises all I remember from matrix classes from high
school.
> I'll try to work out whether QMatrix / QTransform are consistent about it
Thanks, E
On Tuesday, 26 May 2020 08:59:09 PDT Thiago Macieira wrote:
> Neither QMatrix nor QTransform have seen any change since the Qt 5.0
> repository import that was related to the underlying math. Only licensing
> and C++ updates.
>
> The task https://bugreports.qt.io/browse/QTBUG-84
meone who understands these
classes take a look?
--
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/lis
ash. It can't be calculated on-the-fly.
--
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
leanly compile also under
> QT_NO_CAST_FROM_ASCII (and obviously use UTF-8, not Latin1), to reap
> compile-time strlen, etc?
All of the above.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel System Software Products
__
ew/QLatin1String.
There are currently no conclusions on QUtf8String and QAnyString, nor on what
the APIs should look like.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel System Software Products
___
Development
269546
My opinion is clear. +1
--
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
-picks are getting -2 from the bot. How do we make it stop?
https://codereview.qt-project.org/c/qt/qtwayland/+/299070
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel System Software Products
___
Development mailin
NT
s.replace('a', 'b');
Should we now have a b with accent? (b́)
--
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
om, QByteArray a.k.a.
> QVector. (Implicit conversion *to* QByteArray might be okay.)
>
> (BTW, is 'byte' QByte or std::byte? Can we possibly achieve the latter?)
There's no QByte and we shouldn't have that type.
std::byte is an enum around the actual byte type (
en converted. This
error checking is similar to the UTF-8 decoding, which would make it as fast
as the UTF-8 decoder in terms of performance for US-ASCII content.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel System Software Products
__
S-ASCII
// 6) US-ASCII and US-ASCII
There are a couple of vector implementations in the Internet (see
branchless.org) that decode the full UTF-8 into UTF-32 in vector at rates
approaching 3 bytes per cycle, which is about the rate of our UTF-8 decoder
when run with US-ASCII content or the rate of
On Thursday, 14 May 2020 12:34:54 PDT Matthew Woehlke wrote:
> On 14/05/2020 14.58, Thiago Macieira wrote:
> > Which is:
> > b) misspelling "iteratable"
>
> Be that as it may, that ship has sailed:
>
>https://www.google.com/search?q=iteratable
>
&g
en doing this with Qt without
> issues (of course as a post process after building Qt and before
> packaging them).
No distro relies on Qt's stripping routines. They all build with -no-strip and
then figure out themselves using their own techniques.
--
Thiago Macieira - thiago.maciei
On Thursday, 14 May 2020 02:21:01 PDT David C. Partridge wrote:
> I'm not sure whether this problem is caused by a bug in moc, or a bug in VS
> Tools.
>
> Problem description is here:
> <https://forum.qt.io/topic/114726/bug-with-moc-parsing-of-include-directorie
> s&g
e QSet with
> std::unordered_set, so we don’t have much gain compared to returning QSet /
> const QSet &.
>
> So, as I said, I do not see the problem. Can we always return views? Yes. Do
> they gives us benefits in every case? No.
Should we do it? Almost never.
--
Thiago M
On Thursday, 14 May 2020 02:33:43 PDT Marc Mutz via Development wrote:
> On 2020-05-14 02:15, Thiago Macieira wrote:
> > On quarta-feira, 13 de maio de 2020 01:41:26 PDT Иван Комиссаров wrote:
> >> std::span Project::productsSpan() const & { return
> >> d->
On quarta-feira, 13 de maio de 2020 01:41:26 PDT Иван Комиссаров wrote:
> std::span Project::productsSpan() const & { return d->products; }
> std::span Project::productsSpan() const && = delete;
Now implement either or both of these functions if internally you have a
QSet.
can be done.
The idea is indeed to offload the majority of the non-mutating methods to the
same functions, from inline code. There's no reason to have both
QString::indexOf and QStringView::indexOf entry points in the library.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Sof
nput
> is *already* a QString, the function can make a shared copy rather than
> constructing a brand new one. However, it would be nice for such
> functions to offer r-value reference overloads for cases where a QString
> needs to be created, or if the user is done wi
determine what the API should be without looking at the
implementation of those two functions.
--
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
have is static polymorphism, and that's what we
> should continue to have.
Agreed, but also because many of the methods in QStringView are not applicable
to QString.
QStringView::mid(), for example, returns QStringView, but QString::mid()
returns QString.
QString is neither a spe
t;" wouldn't and in some cases, we
would be able to use it without memory allocations either -- that is,
QStringLiteral().
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel System Software Products
__
how it may be used. Unlike QLatin1String, direct
UTF-16-to-UTF-8 comparisons as easy, so the QString methods that would take
QUtf8View are necessarily slower. If space is a constraint but not runtime, it
might be best to just use QString constructor.
--
Thiago Macie
can reasonably assume any Windows 10 version supported by
Microsoft. Older versions may still be in use, but I don't know if we need to
worry about them too much.
Windows 8.1 is a different story. I'll leave that discussion up to others.
--
Thiago Macieira - thiago.macieira (AT) intel.
ect the majority of
the market of the application in question. Most Windows legacy encodings are
single-byte.
In any case, this is about the console output. I think we simply shouldn't
bother, it's not worth the headache it may cause, even if it's unlik
-bit API, especially the Windows 8-bit
API ("A" functions). Those applications may have a lot of legacy code they've
been carrying for decades. They may be using third-party Windows-only
libraries that haven't been updated to deal with multibyte encodings and
simply can&#x
On Saturday, 2 May 2020 18:59:14 PDT Thiago Macieira wrote:
> On Saturday, 2 May 2020 17:50:52 PDT Thiago Macieira wrote:
> > Cannot open foreign types file /home/tjmaciei/obj/qt/qt5-clang/qtbase/lib/
> > metatypes/qt5network.t_metatypes.json
> >
> > Someone please
nymore. But for Qt 6 and the new
buildsystem, we can relearn.
Please make sure that it's enabled in the CI, though.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel System Software Products
___
Development mailing
ed functions.
>
> I'd like to be proven wrong though
Thanks for the info, Albert.
I've suppressed the warning then:
https://codereview.qt-project.org/c/qt/qtbase/+/299195
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software
On Friday, 14 February 2020 05:59:47 PDT Morten Sørvig wrote:
> > https://github.com/KDE/krdc/tree/master
>
> Thanks, I’ll see if I can get krdc running in a VM here.
>
> Morten
Any update?
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Int
t doesn't apply, then I'll fix it.
In two or three months.
--
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
he relevant changes to dev
(without ever building dev).
--
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
h?
b) retarget them all to dev Pick-To headers and stage ASAP?
c) wait 3 weeks and do (b).
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel System Software Products
___
Development mailing list
Development@qt-project.
On Saturday, 2 May 2020 17:50:52 PDT Thiago Macieira wrote:
> Cannot open foreign types file /home/tjmaciei/obj/qt/qt5-clang/qtbase/lib/
> metatypes/qt5network.t_metatypes.json
>
> Someone please fix this.
Cannot open foreign types file /home/tjmaciei/obj/qt/qt5-clang/qtbase/li
We have plenty of warnings when building the CUPS plugin to QtPrintSupport
about deprecated methods. See attached.
Any volunteers to go fix this?
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel System Software Products
/home/tjmaciei/src/qt/qt5/qtbase/src
Cannot open foreign types file /home/tjmaciei/obj/qt/qt5-clang/qtbase/lib/
metatypes/qt5network.t_metatypes.json
Someone please fix this.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel System Software Products
On Tuesday, 28 April 2020 08:42:17 PDT Thiago Macieira wrote:
> Another possibility is that some script overrode LC_ALL to "C" so as to get
> non-localised output. Please fix it to override to "C.UTF-8" or something
> that works on a Mac.
Found it: it's the
On Tuesday, 28 April 2020 07:20:33 PDT Thiago Macieira wrote:
> On Monday, 27 April 2020 13:54:13 PDT Simon Hausmann wrote:
> > I looked at the patch again and searched a bit around. I think nl_langinfo
> > is “broken” on macOS but it doesn’t matter: everything seems to be utf-8,
t;UTF-8". Somehow, the CI
either unset that or was run from an environment that didn t have it set in he
first place.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel System Software Products
___
Development maili
or Qt 5's
QList.
--
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 Sunday, 26 April 2020 09:22:00 PDT Thiago Macieira wrote:
> On Thursday, 31 October 2019 14:11:05 PDT Thiago Macieira wrote:
> > Re: https://codereview.qt-project.org/c/qt/qtbase/+/275152 (WIP: Move
> > QTextCodec support out of QtCore)
> > See also: https://www.python.
On Thursday, 31 October 2019 14:11:05 PDT Thiago Macieira wrote:
> Re: https://codereview.qt-project.org/c/qt/qtbase/+/275152 (WIP: Move
> QTextCodec support out of QtCore)
> See also: https://www.python.org/dev/peps/pep-0538/
> https://www.python.org/dev/peps/pep-0540/
Jus
ess. I don't have representative statistics, but I
> guess that the real percentage will be larger.
By Paretto's Law that 80% of the work requires only 20% of the time, 50%
coverage only bought us 10% of the effort. To reach 50% of the effort, you
need a coverage approaching 90%.
--
Thiago
to an extra base class of QList/QVector (QLisstSpecialMethods) so
it is an actual QList. Ditto for QList.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel System Software Products
___
Development mailing list
Dev
ther.
2) No one has volunteered to write such conversion scripts.
And a minor (3) is that automatic conversions seldom look nice and will
require manual retouching anyway.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Syst
801 - 900 of 6776 matches
Mail list logo
