Re: [Development] [SPAM] How bad QList really is

2020-04-28 Thread Giuseppe D'Angelo via Development
On 4/25/20 4:49 PM, André Pönitz wrote: Spam detection software, running on the system "mx.qt-project.org", has identified this incoming email as possible spam. The original [*SIGHS*] We all know the story that began with "We knew for a long time that QList is not a good default co

Re: [Development] [SPAM] How bad QList really is

2020-04-28 Thread Ville Voutilainen
On Tue, 28 Apr 2020 at 10:59, Giuseppe D'Angelo via Development wrote: > > What I see here is a general-purpose random-access container with cheaper > > insertion and deletion at front and in the middle than *vector provides for > > 61.3% of the types, > > This cannot be claimed as a closed resul

Re: [Development] How bad QList really is

2020-04-28 Thread Kevin Kofler
André Pönitz wrote: > [detailed analysis of QList] > If such a container did not exist it would need to be invented. Thanks for your analysis! This basically sums up what I have been arguing all this time, and brings up actual numbers to confirm it. QList and QVector should remain as they are in

Re: [Development] [SPAM] How bad QList really is

2020-04-28 Thread Kevin Kofler
Giuseppe D'Angelo via Development wrote: > 1) First and foremost, in Qt 6 QString, QByteArray, QVector, are bigger > than a pointer (3 times a pointer size). So, in Qt 6: > > * either QList stays unchanged, and now we heap allocate each element > for those cases too (thus it's necessary to know ho

Re: [Development] How bad QList really is

2020-04-28 Thread Christoph Feck
On 04/28/20 11:04, Kevin Kofler wrote: QList and QVector should remain as they are in Qt 5. But ... some developers are not able to understand the difference, so we need to remove one class!!1! ___ Development mailing list Development@qt-project.org

Re: [Development] Qt 6.0.0 initial schedule

2020-04-28 Thread Edward Welbourne
Jani Heikkinen (27 April 2020 14:05) wrote: > And in addition to these normal release milestones we need to have > earlier milestone (Structure and platform freeze) at the end of June > (30.6.2020, just before summer holidays) to lock down modules, target > platforms etc for the release. In that mi

Re: [Development] [SPAM] How bad QList really is

2020-04-28 Thread Giuseppe D'Angelo via Development
Il 28/04/20 11:16, Kevin Kofler ha scritto: * or the SSO gets reverted. It's not SSO. Is there any actual evidence that it is a win in practice? Yes. But it's not SSO. And on what hardware? Enough to justify the adoption in all std::string implementations and in 3rd party ones as well

Re: [Development] [SPAM] How bad QList really is

2020-04-28 Thread Thiago Macieira
On Tuesday, 28 April 2020 00:56:35 PDT Giuseppe D'Angelo via Development wrote: > 1) First and foremost, in Qt 6 QString, QByteArray, QVector, are bigger > than a pointer (3 times a pointer size). So, in Qt 6: And QVariant is 4 pointers, but Qt 5's QVariant is already too big for Qt 5's QList.

Re: [Development] RFC: Defaulting to or enforcing UTF-8 locales on Unix systems

2020-04-28 Thread Thiago Macieira
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, > all system APIs expect it. I think the CI is well configured and the patch > should

Re: [Development] Qt 6.0.0 initial schedule

2020-04-28 Thread Volker Hilsheimer
> On 28 Apr 2020, at 13:39, Edward Welbourne wrote: > > Jani Heikkinen (27 April 2020 14:05) wrote: >> And in addition to these normal release milestones we need to have >> earlier milestone (Structure and platform freeze) at the end of June >> (30.6.2020, just before summer holidays) to lock d

Re: [Development] RFC: Defaulting to or enforcing UTF-8 locales on Unix systems

2020-04-28 Thread Thiago Macieira
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, > > all system API

Re: [Development] RFC: Defaulting to or enforcing UTF-8 locales on Unix systems

2020-04-28 Thread Thiago Macieira
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 test itself. -- Thiago Macieira - thia

Re: [Development] RFC: Defaulting to or enforcing UTF-8 locales on Unix systems

2020-04-28 Thread Simon Hausmann
Hi, AFAICS (from the public coin logs that dump the entire set of environment variables), nothing specifically sets any of the locale environment variables. In fact, no variables are set. You can check for yourself for example from the macOS log from one of the recent qtbase dev integrations:

Re: [Development] [SPAM] How bad QList really is

2020-04-28 Thread Matthew Woehlke
On 28/04/2020 03.56, Giuseppe D'Angelo via Development wrote: 1) First and foremost, in Qt 6 QString, QByteArray, QVector, are bigger than a pointer (3 times a pointer size). So, in Qt 6: * either QList stays unchanged, and now we heap allocate each element for those cases too (thus it's neces

Re: [Development] [SPAM] How bad QList really is

2020-04-28 Thread Giuseppe D'Angelo via Development
Il 28/04/20 21:45, Matthew Woehlke ha scritto: * QList gets adapted so that its internal array allocates 3 * sizeof(void*) per element, so that e.g. Q6StringList won't require a per-item allocation. This would then also avoid allocations for other datatypes, e.g. QStringView, QImage, maybe QVaria