Re: [Development] Views

[Mutz, Marc via Development]

On 2019-05-17 19:47, Scott Bloom wrote:
[...]

Im just going to throw out my 2 bits on this

Please don’t underestimate (and Im not hearing Thiago say this) the
pain, of breaking source compatibility.  Even on Major (5->6) version
changes.


[...]QCanvas[...]QWebKit[...]


When the Qt team, decides to make these changes, it hurts a lot of
developers, who have to justify to their company, I need to spend X
number of months figuring out a solution, to replicate code that was
already working fine...


These are real pain points, yes, because higher-level features, for 
which there are no replacements, have been remove from the core domain 
of Qt: UIs.


I fully agree with you on that one.


From a utopic point of view, Id be fine with, if every Qt container,
and class that has been "mostly" implemented in STL, or the native
language was thrown out.. But as I tell my employees, just because its
in the language now, doesn’t mean we should go through our 2.5 million
lines of code, and re-write every one to use modern C++...


I disagree here with you here, though. You have had nine years now for 
realising that QList is a bad container to use in your code


From 
https://marcmutz.wordpress.com/2010/07/29/sneak-preview-qlist-considered-harmful/ 
(2010):



Run, don’t walk, and fix your new API to not use QList,
or mark your new types as movable (details are in the
patch). Alas, both changes are binary incompatible, so
you can’t do them if you need your code to stay BC.
This might be one of the reasons why QPair and QVector
aren’t “fixed” yet: doing so would change the layout
of the QList instantiated with them :(.

But, at least for new code, there’s no excuse anymore:
Just apply the patch.


You've had anywhere between eight years to manually and now to 
automatically run clang-tidy on your code to port at least those 
variables that name QList to auto, isolating you from the fallout that a 
QList removal would have. If you still use QList in your code today, 
then, I'm sorry, it's your own fault. You follow the development list, 
so the same is true for Q_FOREACH, for you.


You can also use the Qt containers, but restrict yourself to the 
STL-compatible subset of the API. And then the transition is as easy as 
s/QVector/std::vector/. That has been possible since Qt 3.0.


So, this case differs greatly from the two instances of feature removal 
you mentioned above in that you had literally years of time to prepare a 
coding style that would all but isolate you from the exact type of 
container used. The STL containers exist in standard form since 1998, 
and since then you had time to port your own code away from Qt 
containers, further isolating you from one of the most 
code-churn-producing subsystems of Qt: containers. If you've been with 
Qt since Qt 3 or Qt 2, you know what I mean. And if you have not learned 
from Qt 2 -> Qt 3 or Qt 3 -> Qt 4 w.r.t. to containers, then - sorry - 
again: your own fault. Had you ported to STL, your code would stay 
unchanged.


I'm playing devil's advocate here. In reality, yes, I want the rebase of 
Qt onto modern C++, for a great many reasons, but I'm also always 
looking for a way how to do that without disruptive changes. But that 
requires that Qt users compile with deprecated warnings enabled and fix 
their code small steps at a time. There are not many libraries that keep 
SC for so long as Qt does. But very long is not forever, and change will 
come one way or another. The good news is that C++11 allows you to 
insulate your code in many ways (auto, unordered_*), and this is 
precisely why we can now take this step.



To replace out every container, that works today?  And in the process,
break probably billions of lines of existing Qt code, which would have
to be re-written using the new containers???  Please don’t  Even
for 6.0...  Some form of transition would be great.


Upon reading the recent mails in this thread, one could have noticed 
that this whole subthread started with an unrelated topic: _not_ making 
QList an alias to QVector. I'd prefer the discussion to pick up on that 
technical point, even though I appreciate that it's easier to just 
generally vent FUD in a bike-shedding frenzy than to seriously consider 
technical issues such as how we can remove QList with minimal 
disruption.


@all:
I will no longer reply to the Views subthread, because it has gone 
off-track, as usual. Please give your valued input on a way forward 
regarding QList removal (QList subthread).


Have a nice weekend,
Marc
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Views

[Scott Bloom]

Fair enough.. 

But I will say.. all too often.. theory becomes practice
--

Please note that nobody said «we are removing Qt containers in Qt6». At least, 
I don’t have that information.

The discussion is mostly about a *theoretical* case when the implementation of 
a *theoretical* method in a *theoretical* class may *theoretically* change and 
how far we should go to support that *theoretical* change. Or should not =)

It’s been said that Qt6 will be mostly source-compatible with Qt5.

PS: there’s been a discussion about killing QList but it is not clear how to do 
so without breaking half of the world (i.e. no final decision so far) and this 
discussion started long time ago, so you've had (and still have plenty of) time 
to revisit usages of QList in your codebase and replace it with more 
appropriate container.

> 17 мая 2019 г., в 19:47, Scott Bloom  написал(а):
> 
> Maybe, line in the Qt3->4 transition timeframe, have a macro, to "Allow Qt 
> Containers", as well as code that does the autoconversion from Qt to STL, so 
> developer code builds when the flag is on.
> 
> Scott
> ___
> Development mailing list
> Development@qt-project.org
> https://lists.qt-project.org/listinfo/development

___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Views

[Giuseppe D'Angelo via Development]

Il 17/05/19 16:46, Bernhard Lindner ha scritto:

I've done this experiment for QMap / QHash / QSet, where keeping COW at
the cost of an extra indirection (dptr -> [refcount + std:: class] ->
actual data) is more acceptable since these classes jump all over the
memory anyhow. Basically "it worked", still requiring a few changes
though, e.g. std::unordered_map iterators are forward, QHash ones are
bidirectional. If the SIC is acceptable, something to consider for Qt 6.

Are there any plans/discussions how to procede with that experiment?


It was worth a try after we discussed this possibility a couple of years 
ago at QtCS. I don't know if it's still interesting to pursue.


Thanks,
--
Giuseppe D'Angelo | giuseppe.dang...@kdab.com | Senior Software Engineer
KDAB (France) S.A.S., a KDAB Group company
Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com
KDAB - The Qt, C++ and OpenGL Experts



smime.p7s
Description: Firma crittografica S/MIME
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Views

[Иван Комиссаров]

Please note that nobody said «we are removing Qt containers in Qt6». At least, 
I don’t have that information.

The discussion is mostly about a *theoretical* case when the implementation of 
a *theoretical* method in a *theoretical* class may *theoretically* change and 
how far we should go to support that *theoretical* change. Or should not =)

It’s been said that Qt6 will be mostly source-compatible with Qt5.

PS: there’s been a discussion about killing QList but it is not clear how to do 
so without breaking half of the world (i.e. no final decision so far) and this 
discussion started long time ago, so you've had (and still have plenty of) time 
to revisit usages of QList in your codebase and replace it with more 
appropriate container.

> 17 мая 2019 г., в 19:47, Scott Bloom  написал(а):
> 
> Maybe, line in the Qt3->4 transition timeframe, have a macro, to "Allow Qt 
> Containers", as well as code that does the autoconversion from Qt to STL, so 
> developer code builds when the flag is on.
> 
> Scott
> ___
> Development mailing list
> Development@qt-project.org
> https://lists.qt-project.org/listinfo/development

___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Views

[Scott Bloom]

On Friday, 17 May 2019 09:38:05 PDT Marco Bubke wrote:
> Thiago, you partially implying that BC is still needed but with 
> technologies like flatpak or snappy this will maybe not common use 
> case anymore. They provide even behaviour compatibility if you stay with the 
> same runtime.
> Something which is not provided by binary compability. I personally 
> think if the behaviour is changed it should not even compile anymore 
> so you can fix it easily.

Some level of compatibility is of course required, unless you're proposing we 
provide a certain level of bugfixing for ALL releases for a number of years. 
That is, if 6.2 isn't source-compatible with 6.1, then 6.1 needs to be 
supported for 3+ years with bugfixes for code that was ported to 6.1 but hasn't 
been ported further to 6.2.

If we're still keeping source compatibility but not binary, the problem is not 
as big as above. But it still exists if you're not in a position to recompile 
all modules (think third party's component).

--
Im just going to throw out my 2 bits on this

Please don’t underestimate (and Im not hearing Thiago say this) the pain, of 
breaking source compatibility.  Even on Major (5->6) version changes.

Qt lost a lot of momentum, but eventually gained it back, in the 3-4 
transition.  And it was more than just "the code didn’t compile" it was also, 
lost functionality that was take from 3, a hack added in 4.1 (missing in 4.0 
IIRC) and then fully replaced in 4.4.. And Im talking about the Graphics 
Scene/View...

We have a similar issue, even if it has been 2-3 years already, with the change 
in web viewer... I know of more than one project, including my product, that is 
stuck on an old version of Qt, simply because the new web view, is missing some 
functionality.  And building the old browser classes is a less than "wonderful" 
solution.

When the Qt team, decides to make these changes, it hurts a lot of developers, 
who have to justify to their company, I need to spend X number of months 
figuring out a solution, to replicate code that was already working fine...

From a utopic point of view, Id be fine with, if every Qt container, and class 
that has been "mostly" implemented in STL, or the native language was thrown 
out.. But as I tell my employees, just because its in the language now, doesn’t 
mean we should go through our 2.5 million lines of code, and re-write every one 
to use modern C++...

To replace out every container, that works today?  And in the process, break 
probably billions of lines of existing Qt code, which would have to be 
re-written using the new containers???  Please don’t  Even for 6.0...  Some 
form of transition would be great.

Maybe, line in the Qt3->4 transition timeframe, have a macro, to "Allow Qt 
Containers", as well as code that does the autoconversion from Qt to STL, so 
developer code builds when the flag is on.

Scott
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Views

[Thiago Macieira]

On Friday, 17 May 2019 09:38:05 PDT Marco Bubke wrote:
> Thiago, you partially implying that BC is still needed but with technologies
> like flatpak or snappy this will maybe not common use case anymore. They
> provide even behaviour compatibility if you stay with the same runtime.
> Something which is not provided by binary compability. I personally think
> if the behaviour is changed it should not even compile anymore so you can
> fix it easily.

Some level of compatibility is of course required, unless you're proposing we 
provide a certain level of bugfixing for ALL releases for a number of years. 
That is, if 6.2 isn't source-compatible with 6.1, then 6.1 needs to be 
supported for 3+ years with bugfixes for code that was ported to 6.1 but 
hasn't been ported further to 6.2.

If we're still keeping source compatibility but not binary, the problem is not 
as big as above. But it still exists if you're not in a position to recompile 
all modules (think third party's component).

-- 
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

Re: [Development] Views

[Marco Bubke]

Thiago, you partially implying that BC is still needed but with technologies 
like flatpak or snappy this will maybe not common use case anymore. They 
provide even behaviour compatibility if you stay with the same runtime. 
Something which is not provided by binary compability. I personally think if 
the behaviour is changed it should not even compile anymore so you can fix it 
easily.

On May 17, 2019 17:08:28 Thiago Macieira  wrote:

> On Thursday, 16 May 2019 11:18:08 PDT Mutz, Marc via Development wrote:
>> > When you first design the class, sure. But 5 years later, you may have
>> > the
>> > data internally kept in a QMap or QHash, mapped to some other
>> > information. So
>> > your function that used to "return d->member;" now does
>> > "return d->member.keys();"
>>
>> Can you point out a Qt class where this was the case in the past?
>
> I'll have to look it up, but it has happened in the past and if not in Qt,
> then in one of the KDE libraries. The Library API Design Policy includes this
> particular point (don't return references) for a reason.
>
>> > Another case would be where you're keeping extra data in the internal
>> > structure and you need to filter that out before returning. Or the
>> > dual:
>> > augment with some implied data. The latter could be quite common if the
>> > class
>> > is not storing anything in the regular case, but synthesising it on
>> > demand for
>> > the benefit of the old API.
>>
>> This one is simple: Array of struct -> struct of arrays. Well-known
>> optimisation in the games industry.
>
> Sure, but if you returned a view of structs, how would you later make that
> view of structs work with your internally-stored struct of arrays?
>
>> > But only so long as each of those containers store lay the data out the
>> > same
>> > way in memory, which is not the case for my QMap example.
>>
>> You basically have a dichotomy: Either you have contiguous storage, in
>> which case you return pointers, or you have non-contiguous storage, in
>> which case you need some form of runtime-dispatch Iterator Pattern.
>
> Or you have a well-known storage pattern, in which case you don't return an
> array of pointers (which would need to be allocated anyway), but you return a
> means of finding those elements. That's what the containers do for you.
>
> So I don't have a problem returning a type that is cheap when you're designing
> the API, so long as you don't lock yourself into it if you later want to
> change. I don't see anything but actual containers here.
>
>> I don't think you'd ever come into a situation where you'd need to
>> switch from one to the other. If you think so, please provide an example
>> where this was necessary in the past.
>
> I'll look it up. Note that in hindsight all of those will look like bad
> design, but the point is that we didn't know any better when the design was
> first done.
>
>> > Two of your examples [QRegion, QGradient] basically return an internal
>> > structure, so I'm not seeing
>> > how they are relevant.
>>
>> How are they not relevant? Because the class basically _is_ a container?
>> Well, then see QAIM::roleNames(). Apart from the questionable design to
>> return a node-based associative container for the O(10) elements in
>> there, instead of a (view to a) sorted array of structs[1], it is a
>> prime example of how the API requires a particular implementation. I
>> don't remember whether it returns a QMap or a QHash, but either way, one
>> might want to return the other, down the road - or even depending on the
>> number of elements in the container, like QRegion does.
>
> I meant they are not good examples because they always return something that
> currently is stored in the d pointer. So there's no problem in changing them
> to return a view to that storage, since that storage does not go out of scope
> at function exit.
>
>> For an example of where roleNames() goes horribly wrong, see
>> QQmlListModel. Is has the data stored elsewhere and re-constructs a
>> QHash each time it's called. With a runtime iterator, it could probably
>> produce the values on the fly, and with a sorted array of {role, name}
>> it would allocate one block of memory per call, not O(n).
>
> I don't understand what you meant here. Are you advocating that the return
> type should have been different? What type would have helped?
>
> Or are you saying that if we had different tools internally, the
> implementation of QQmlListModel::roleNames could have been better?
>
> Either way, this is a very good example for why the return type mustn't be a
> reference or a non-owning container: the two sources for the function are not
> compatible with the return type.
>
>> > How would you implement this one with a view-based return?
>>
>> Glad you asked:
>>
>>  static constexpr QGradientStop defaultStops[] = {{0,
>> QColorLiterals::black}, {1, QColorLiterals::white}};
>>  return SomeView{std::begin(defaultStops), std::end(defaultStops)};
>>
>> Instead of the simple s

Re: [Development] Views

[zoltan . lutor]

My not (that) complex mobile app (game) used almost entirely QML/Javascript - 
but when I needed mutual exclusion/atomicity I have not figured out anything 
but going back to good, old C++...

And as mentioned below, wide variety of containers/datatypes, algorithms, etc...

So yes, perforrmance is one driver but not the only one...

Br,

Zoltan

Ps: if I happened to miss some QML/Javascript magic the helps solving mutual 
exclusion/atomicity, let me  know... ;)

On Friday, May 17, 2019, Philippe wrote:
> > No-one uses C++ unless they need the extra performance.
> 
> This is mostly right, though wide portability can be another reason.
> 
> This being said, that does not mean that every line of a C++ application
> needs to be optimized with CPU cycles in mind.
> In my experience, only restricted portions need to be optimized (desktop
> application developer here).
> 
> This is why I use Qt containers when I need convenience, and specialized
> containers when I need speed. And in that last case, that depend on the
> context (eg. there are a variery of map implementations, each one with some
> advantages).
> 
> If we had a magic stick to switch all Qt containers to the STL library
> containers, that would not prevent the need to use dedicated
> containers when speed really matters. Hence, I am fine with today Qt
> containers.
> 
> And today, I can quote an example of an important container that Qt
> provides but that C++20 does not (correct me if I am wrong):
> QVarLengthArray (even if, here again, they are faster implementations
> when one (rarely) need move semantics support).
> 
> Philippe
> 
> On Fri, 17 May 2019 07:47:55 +0200
> "Mutz, Marc via Development"  wrote:
> 
> > On 2019-05-16 23:41, Konstantin Shegunov wrote:
> > > you end up where the STL is - so convoluted it's hardly worth making
> > > anything with it.
> > 
> > Qt is a C++ library. If you don't like C++, either stay in QML or use 
> > Java. No-one uses C++ unless they need the extra performance.
> > 
> > It is not Qt's job to change the decisions made by the C++ standards 
> > committee. If you want to change the STL, submit a paper to WG21, not 
> > rant on a Qt mailing-list.
> > 
> > Thanks,
> > Marc
> > ___
> > Development mailing list
> > Development@qt-project.org
> > https://lists.qt-project.org/listinfo/development
> 
> 
> ___
> Development mailing list
> Development@qt-project.org
> https://lists.qt-project.org/listinfo/development
>
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Views

[Thiago Macieira]

On Thursday, 16 May 2019 11:18:08 PDT Mutz, Marc via Development wrote:
> > When you first design the class, sure. But 5 years later, you may have
> > the
> > data internally kept in a QMap or QHash, mapped to some other
> > information. So
> > your function that used to "return d->member;" now does
> > "return d->member.keys();"
> 
> Can you point out a Qt class where this was the case in the past?

I'll have to look it up, but it has happened in the past and if not in Qt, 
then in one of the KDE libraries. The Library API Design Policy includes this 
particular point (don't return references) for a reason.

> > Another case would be where you're keeping extra data in the internal
> > structure and you need to filter that out before returning. Or the
> > dual:
> > augment with some implied data. The latter could be quite common if the
> > class
> > is not storing anything in the regular case, but synthesising it on
> > demand for
> > the benefit of the old API.
> 
> This one is simple: Array of struct -> struct of arrays. Well-known
> optimisation in the games industry.

Sure, but if you returned a view of structs, how would you later make that 
view of structs work with your internally-stored struct of arrays?

> > But only so long as each of those containers store lay the data out the
> > same
> > way in memory, which is not the case for my QMap example.
> 
> You basically have a dichotomy: Either you have contiguous storage, in
> which case you return pointers, or you have non-contiguous storage, in
> which case you need some form of runtime-dispatch Iterator Pattern.

Or you have a well-known storage pattern, in which case you don't return an 
array of pointers (which would need to be allocated anyway), but you return a 
means of finding those elements. That's what the containers do for you.

So I don't have a problem returning a type that is cheap when you're designing 
the API, so long as you don't lock yourself into it if you later want to 
change. I don't see anything but actual containers here.

> I don't think you'd ever come into a situation where you'd need to
> switch from one to the other. If you think so, please provide an example
> where this was necessary in the past.

I'll look it up. Note that in hindsight all of those will look like bad 
design, but the point is that we didn't know any better when the design was 
first done.

> > Two of your examples [QRegion, QGradient] basically return an internal
> > structure, so I'm not seeing
> > how they are relevant.
> 
> How are they not relevant? Because the class basically _is_ a container?
> Well, then see QAIM::roleNames(). Apart from the questionable design to
> return a node-based associative container for the O(10) elements in
> there, instead of a (view to a) sorted array of structs[1], it is a
> prime example of how the API requires a particular implementation. I
> don't remember whether it returns a QMap or a QHash, but either way, one
> might want to return the other, down the road - or even depending on the
> number of elements in the container, like QRegion does.

I meant they are not good examples because they always return something that 
currently is stored in the d pointer. So there's no problem in changing them 
to return a view to that storage, since that storage does not go out of scope 
at function exit.

> For an example of where roleNames() goes horribly wrong, see
> QQmlListModel. Is has the data stored elsewhere and re-constructs a
> QHash each time it's called. With a runtime iterator, it could probably
> produce the values on the fly, and with a sorted array of {role, name}
> it would allocate one block of memory per call, not O(n).

I don't understand what you meant here. Are you advocating that the return 
type should have been different? What type would have helped?

Or are you saying that if we had different tools internally, the 
implementation of QQmlListModel::roleNames could have been better?

Either way, this is a very good example for why the return type mustn't be a 
reference or a non-owning container: the two sources for the function are not 
compatible with the return type.

> > How would you implement this one with a view-based return?
> 
> Glad you asked:
> 
>  static constexpr QGradientStop defaultStops[] = {{0,
> QColorLiterals::black}, {1, QColorLiterals::white}};
>  return SomeView{std::begin(defaultStops), std::end(defaultStops)};
> 
> Instead of the simple solution shown here, what we'll more likely see is
> QVector::fromRawData(). Which is trying to retrofit a view onto an
> owning container. Yuck.

It's a price we pay for flexibility. No doubt that a view is much cheaper to 
constructor, pass and destruct. But it's also more limited.

-- 
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/develop

Re: [Development] Views

[Bernhard Lindner]

> I've done this experiment for QMap / QHash / QSet, where keeping COW at 
> the cost of an extra indirection (dptr -> [refcount + std:: class] -> 
> actual data) is more acceptable since these classes jump all over the 
> memory anyhow. Basically "it worked", still requiring a few changes 
> though, e.g. std::unordered_map iterators are forward, QHash ones are 
> bidirectional. If the SIC is acceptable, something to consider for Qt 6.

Are there any plans/discussions how to procede with that experiment?

-- 
Best Regards
Bernhard Lindner

___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

[Development] Coin production update 1.0-rc patch version 1

[Aapo Keskimölö]

Hi all,


Following the previous baseline, I have have updated coin production to 
1.0-rc patch version 1:

  https://testresults.qt.io/ci/aakeskim/production_updates/HEAD

  https://testresults.qt.io/ci/aakeskim/production_updates/changelog_20190517

  https://testresults.qt.io/ci/aakeskim/production_updates/cherrypicks


Summary:

  - Several bug fixes: Source archive creation and getting WorkItem 
timeouts.

  - Running integrations can now be resolve their WorkItems in parallel.

  - Running integrations are now published to remote Coin webservers.

  - Listing configurations is was optimized and should be faster after 
being triggered from Webui.

  - Nightly builds can be modified via the Webui and now also support 
product branch fields.

  - Fixed configure arguments changes slipping by untested in CI (sorry 
about the terrible plunder!).

  - Several module instructions updates, see changelog link above.


Kind regards,

Aapo

___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Nominating Mikhail Svetkin for Approver status

[Simon Hausmann]

+1


Simon

From: Development  on behalf of Shawn 
Rutledge 
Sent: Friday, May 17, 2019 14:29
To: Qt development mailing list
Subject: Re: [Development] Nominating Mikhail Svetkin for Approver status

+1
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Nominating Ryan Chu for Approvership

[Simon Hausmann]

+1


Simon

From: Development  on behalf of Jesus 
Fernandez 
Sent: Friday, May 17, 2019 8:57
To: development@qt-project.org
Subject: Re: [Development] Nominating Ryan Chu for Approvership

+1!




Best regards,

Jesús


From: Development  on behalf of Edward 
Welbourne 
Sent: 16 May 2019 10:58
To: Paul Wicking; development@qt-project.org
Subject: Re: [Development] Nominating Ryan Chu for Approvership

Another +1.

Disclaimer: I was his mentor and office-mate for his first year and a bit.

Eddy.


From: Development  on behalf of Paul 
Wicking 
Sent: 15 May 2019 13:11
To: development@qt-project.org
Subject: [Development] Nominating Ryan Chu for Approvership

I'd like to nominate Ryan Chu for approvership. He's been an active
contributor since January 2018, working mostly on the Docker-based test
server and network-related code. He is also an active reviewer, and his
manner of communication upholds the values as set forth by the Qt Code
of Conduct.

I know Ryan as a humble and honest person. I trust he will treat this
role with the utmost respect and care, as is required.


If you're curious, here's a list of his changes:

https://codereview.qt-project.org/#/q/owner:%22Ryan+Chu%22,n,z

and a list of changes he's on as a reviewer:

https://codereview.qt-project.org/#/q/reviewer:%22Ryan+Chu%22,n,z


Disclaimer: he sits 4 offices down the hall from me, and we're both on
the Core & Network team.


--
Paul Wicking
Documentation Engineer

The Qt Company
Sandakerveien 116
0484, Oslo, Norway
paul.wick...@qt.io
+47 90 500 666
http://qt.io
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Nominating Mikhail Svetkin for Approver status

[Shawn Rutledge]

+1
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Views

[Mutz, Marc via Development]

On 2019-05-17 11:36, Philippe wrote:
[...]

QVarLengthArray
While it is true that there's no such container, it's even more true
that there will never be one. Because C++ made the allocators, which
back in the 90s were just a way to handle near and far pointers on 
older

architectures, fit for actually abstracting allocation.


I don't know why you say there will never be such a standard allocator.

[...]

That may be because I didn't :O

In fact, I'd expect that some of the BDE allocators will eventually make 
it into the standard.


What I don't expect is to have stuff like inline_vector in the standard, 
because it's easy to replace (with a few elements lost) by vector + pool 
allocator + char[] buffer.

___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Views

[Philippe]

> I start wondering if it is possible to wrap the STL containers in Qt6 and 
> give them a
> nice, intuitive, Qt-like API while still providing full STL compatibility. I 
> am sure this
> has been evaluated. Are the results documented somewhere?

A few years ago my application was affected by a bug found on
std::vector MSVC and not CLang/XCode.

Therefore, for me this is not such a good idea, because for a
cross-platform application, I like the containers to behave exactly the
same. Both in terms of performances and potential bugs. I mean, the STL
provides a uniform interface, not a same implementation, according to
the compiler's supplied library.

Philippe

___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Views

[Philippe]

>Please watch one of Lakos' recent allocator's talks for a ton of benchmarks 
>how a custom 
> allocator helps speed up - not just std::vector but also std::map, if 
> one is so inclined.

I fully agree with this topic (and kudos for Lakos in general).
That's actually a lack in Qt containers: no allocation customization
possible.

Allocators help a lot, but when it's a matter of maps, there are many
other aspects coming into play.

> QVarLengthArray
> While it is true that there's no such container, it's even more true 
> that there will never be one. Because C++ made the allocators, which 
> back in the 90s were just a way to handle near and far pointers on older 
> architectures, fit for actually abstracting allocation.

I don't know why you say there will never be such a standard allocator.
For example, eastl has such a container with custom allocator:
https://github.com/questor/eastl/blob/master/fixed_vector.h#L71
(cf. OverflowAllocator)

There is also a recent c++ proposal:
http://open-std.org/JTC1/SC22/WG21/docs/papers/2018/p0843r1.html

BTW, this article fails to mention a recent excellent contribution from google
/ abseil
https://github.com/abseil/abseil-cpp/blob/master/absl/container/inlined_vector.h

> There is no readability difference between the use of a Qt container
> and that of an STL container.

I have a different opinion of this. And this is what I mean when I say
that Qt containers are convenient.

Philippe

___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Views

[Giuseppe D'Angelo via Development]

Il 17/05/19 09:35, Bernhard Lindner ha scritto:

I start wondering if it is possible to wrap the STL containers in Qt6 and give 
them a
nice, intuitive, Qt-like API while still providing full STL compatibility. I am 
sure this
has been evaluated. Are the results documented somewhere?


I've done this experiment for QMap / QHash / QSet, where keeping COW at 
the cost of an extra indirection (dptr -> [refcount + std:: class] -> 
actual data) is more acceptable since these classes jump all over the 
memory anyhow. Basically "it worked", still requiring a few changes 
though, e.g. std::unordered_map iterators are forward, QHash ones are 
bidirectional. If the SIC is acceptable, something to consider for Qt 6.


My 2 c,
--
Giuseppe D'Angelo | giuseppe.dang...@kdab.com | Senior Software Engineer
KDAB (France) S.A.S., a KDAB Group company
Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com
KDAB - The Qt, C++ and OpenGL Experts



smime.p7s
Description: Firma crittografica S/MIME
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Views

[Mutz, Marc via Development]

On 2019-05-17 08:12, Philippe wrote:

No-one uses C++ unless they need the extra performance.


This is mostly right, though wide portability can be another reason.

This being said, that does not mean that every line of a C++ 
application

needs to be optimized with CPU cycles in mind.
In my experience, only restricted portions need to be optimized 
(desktop

application developer here).

This is why I use Qt containers when I need convenience, and 
specialized

containers when I need speed. And in that last case, that depend on the
context (eg. there are a variery of map implementations, each one with 
some

advantages).

If we had a magic stick to switch all Qt containers to the STL library
containers, that would not prevent the need to use dedicated
containers when speed really matters. Hence, I am fine with today Qt
containers.


There is no readability difference between the use of a Qt container and 
that of an STL container. Don't confuse familiarity with 
simplicity. If two things are equally readable (I 
emphasize: readable; it doesn't matter that it takes more LOC to code 
it, cf. QSpinBox ctor Qt 3 vs. Qt 4), then you should use the more 
performant one. And please go back in time and read up on what I wrote 
about Q_FOREACH and how it _hurts_ readability.


The Qt containers used to outperform the STL ones on major compilers all 
the way into the oughts, but they no longer do and the std containers 
have gained a lot of features. Qt has had eight years time to catch up, 
and didn't. The focus of Qt lies elsewhere now, and so it should be. But 
Qt should realize that and regularly rebase on a C++ version it can 
minimally support on all platforms. Currently, that's C++11. A rebase 
helps with the interop with other libraries, and tools (tsan, anyone?) 
and, something all the oldtimers seem to forget: people who learn C++ 
_today_ learn unordered_map. They learn std::mutex. They will likely ask 
what, then QHash is for and why there's QMutex, but not QRecursiveMutex. 
Why Qt classes can be held in std::map, but not in std::unordered_map. 
And why they need to learn a different API for containers from the one 
they already know.


Qt is building up a tradition. Traditions are good for society, but in 
sw development, we call them technical debt, and realize that growing TD 
binds resources better spent elsewhere.



And today, I can quote an example of an important container that Qt
provides but that C++20 does not (correct me if I am wrong):
QVarLengthArray (even if, here again, they are faster implementations
when one (rarely) need move semantics support).


While it is true that there's no such container, it's even more true 
that there will never be one. Because C++ made the allocators, which 
back in the 90s were just a way to handle near and far pointers on older 
architectures, fit for actually abstracting allocation. Please watch one 
of Lakos' recent allocator's talks for a ton of benchmarks how a custom 
allocator helps speed up - not just std::vector but also std::map, if 
one is so inclined.


Thanks,
Marc
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Views

[Konstantin Shegunov]

On Fri, May 17, 2019 at 8:49 AM Mutz, Marc via Development <
development@qt-project.org> wrote:

> Qt is a C++ library. If you don't like C++, either stay in QML or use
> Java. No-one uses C++ unless they need the extra performance.
>

I may or may not like where C++ is going, but that's really beside the
point. I don't, and I believe sensibly, optimize every single line in what
I write. I don't shy away from doing it where it matters, but certainly I
appreciate convenience where it hardly matters. Primarily I work without UI
so I don't see why QML or Java would be at all relevant.


> It is not Qt's job to change the decisions made by the C++ standards
> committee.


I never said it's the case. Are we talking about their decisions or the Qt
project's?


> If you want to change the STL, submit a paper to WG21, not
> rant on a Qt mailing-list.
>

There was no rant. Just how I saw the case from the user side, granted
written with some bitterness. Not everything that doesn't profess the STL
as the greatest thing since the sliced bread can or should automatically be
classified as a rant. I had written 3 more paragraphs in that particular
email.
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Gerrit: Scheduled maintenance 20 May 2019

[Volker Hilsheimer]

Great that this is finally happening, hope all goes well with the upgrade!

Volker



From: Development  on behalf of Jukka 
Jokiniva 
Sent: Friday, May 17, 2019 09:37
To: development@qt-project.org
Subject: [Development] Gerrit: Scheduled maintenance 20 May 2019

Dear all,

Please read carefully, as this email contains important information.

We would like to remind you that codereview.qt-project.org will be unavailable 
due to scheduled maintenance. The aim is to upgrade our Gerrit Code Review to 
the latest version, 2.16. This upgrade includes a range of new features and a 
new web UI. Please refer to the public wiki for further information, 
https://wiki.qt.io/Gerrit_Upgrade_2019.

AFFECTED SYSTEMS
Gerrit Code Review (codereview.qt-project.org)
COIN (the continuous integration system)

DATE AND TIME
Monday, 20 May 2019.
Start: 06:00 EET (UTC + 2).
Estimated end: 18:00 EET (UTC + 2).

During this time, codereview.qt-project.org will be unavailable.
Furthermore, staging rights will be temporarily removed for ALL USERS on SUNDAY 
19 MAY 1800 EET (CET + 2). Any on-going integrations in COIN will be canceled 
and both services will be shut down when the maintenance break starts.

We will send an alert before shutting down the system Monday morning. Upon 
successful completion, all access will be restored and we will notify the 
mailing lists accordingly.


Best regards,

your friendly Gerrit admin team.


___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Views

[Bernhard Lindner]

> you end up where the STL is - so convoluted it's hardly worth making
> anything with it.

I agree. The horrid of STL was one of the reasons for me to use Qt. Everything 
is
complicated to the maximum in STL. Qt is so much more intuitive, it is fast to 
learn and
fun to use (except when hitting a long reported bug... again).

On the other hand, when reading the ML threads about containers in Qt and their 
limited
STL compatibility, plus the QList issue, plus the need to update containers to 
x64, plus
the fact that the Qt project has not enough man power to do everything that 
should be
done... 

I start wondering if it is possible to wrap the STL containers in Qt6 and give 
them a
nice, intuitive, Qt-like API while still providing full STL compatibility. I am 
sure this
has been evaluated. Are the results documented somewhere?

-- 
Best Regards, 
Bernhard

___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

[Development] Gerrit: Scheduled maintenance 20 May 2019

[Jukka Jokiniva]

Dear all,

Please read carefully, as this email contains important information.

We would like to remind you that codereview.qt-project.org will be unavailable 
due to scheduled maintenance. The aim is to upgrade our Gerrit Code Review to 
the latest version, 2.16. This upgrade includes a range of new features and a 
new web UI. Please refer to the public wiki for further information, 
https://wiki.qt.io/Gerrit_Upgrade_2019.

AFFECTED SYSTEMS
Gerrit Code Review (codereview.qt-project.org)
COIN (the continuous integration system)

DATE AND TIME
   Monday, 20 May 2019.
   Start: 06:00 EET (UTC + 2).
   Estimated end: 18:00 EET (UTC + 2).

During this time, codereview.qt-project.org will be unavailable.
Furthermore, staging rights will be temporarily removed for ALL USERS on SUNDAY 
19 MAY 1800 EET (CET + 2). Any on-going integrations in COIN will be canceled 
and both services will be shut down when the maintenance break starts.

We will send an alert before shutting down the system Monday morning. Upon 
successful completion, all access will be restored and we will notify the 
mailing lists accordingly.


Best regards,

your friendly Gerrit admin team.


___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

[Development] IFW 3.1.1 released

[Katja Marttila]

Hi,
We have published IFW version 3.1.1. You can get it via online installer or 
download a standalone installer. Also new versions of Qt Online Installers and 
Maintenance Tools are available based on 3.1.1.


Katja Marttila
Software Engineer

The Qt Company
Elektroniikkatie 13
90590, Oulu, Finland
katja.martt...@qt.io
http://qt.io
[The Qt Company logo]
[Facebook]
[Twitter]
[LinkedIn]
[Google+]
[YouTube]


___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Nominating Ryan Chu for Approvership

[Jesus Fernandez]

+1!




Best regards,

Jesús


From: Development  on behalf of Edward 
Welbourne 
Sent: 16 May 2019 10:58
To: Paul Wicking; development@qt-project.org
Subject: Re: [Development] Nominating Ryan Chu for Approvership

Another +1.

Disclaimer: I was his mentor and office-mate for his first year and a bit.

Eddy.


From: Development  on behalf of Paul 
Wicking 
Sent: 15 May 2019 13:11
To: development@qt-project.org
Subject: [Development] Nominating Ryan Chu for Approvership

I'd like to nominate Ryan Chu for approvership. He's been an active
contributor since January 2018, working mostly on the Docker-based test
server and network-related code. He is also an active reviewer, and his
manner of communication upholds the values as set forth by the Qt Code
of Conduct.

I know Ryan as a humble and honest person. I trust he will treat this
role with the utmost respect and care, as is required.


If you're curious, here's a list of his changes:

https://codereview.qt-project.org/#/q/owner:%22Ryan+Chu%22,n,z

and a list of changes he's on as a reviewer:

https://codereview.qt-project.org/#/q/reviewer:%22Ryan+Chu%22,n,z


Disclaimer: he sits 4 offices down the hall from me, and we're both on
the Core & Network team.


--
Paul Wicking
Documentation Engineer

The Qt Company
Sandakerveien 116
0484, Oslo, Norway
paul.wick...@qt.io
+47 90 500 666
http://qt.io
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development