Re: [Development] unique_ptr and Qt, Take 2

[Daniel Teske]

Am 06.05.2019 um 12:04 schrieb Lars Knoll:


On 6 May 2019, at 10:27, Konstantin Shegunov > wrote:


On Mon, May 6, 2019 at 10:42 AM Lars Knoll > wrote:


Not sure whether it’s most projects, but there certainly are
users doing it. And we’ve been using the pattern in our examples
in some cases as well. But I can relate to Allan that creating
widgets on the stack is bad style (as it conflicts with the way
we memory manage them), and if I’d have a choice today, I would
probably prefer to enforce them to be created on the heap by some
means.


Fine, there seems to be somewhat of an argument in that regard. I'd 
raise the question then, what should be done for QObject derived 
classes, and I don't mean the ones that come from Qt (i.e. QFile, 
which Thiago mentioned), but the ones the user defines. In the end 
QObject is for us to derive from - get signals and slots and all 
those goodies. But then if one restricts QObject to be on the heap 
how do we treat the user classes? What I mean is - you can control 
how allocations happen in the library, say you provide custom 
new/delete for QObject and/or QWidget and restrict the stack 
(presumably through some trickery that disables the constructor), 
does this mean we are to force the user to write their own allocation 
operators for their classes? This doesn't really sound practical to 
say the least. Moreover there's really little reason (from the user's 
point of view) to have something in the heap if it can go on the 
stack. What do we do with QCoreApplicaiton, force the heap on it?


It’s somewhat of a philosophical discussion now, as we are where we 
are and users can and are creating QObject’s on the stack. I don’t 
think we can change that now (even for Qt 6), and restricting it would 
lead to rather ugly syntax in C++ (as the language doesn’t really help 
enforcing something like this). So that means we’ll have to continue 
to support it.


That's something that needs to be taken into account in any change in 
how memory management could work in Qt6. The patch I propose does not 
take that into account and is indeed almost entirely source compatible. 
(No changes in Qt Creator required, and two minor changes in tests.)


And the constructors/apis that are marked with QT_UNSAFE_API by default 
don't even emit any warning. The user can opt into those warnings.


One thing I forgot to mention, which is something I only have a mediocre 
solution for is, modal QDialogs (or any other top level widgets) on the 
stack. For those the parent pointer is both the owner and indicates to 
which parent the dialog is modal. In my opinion, the best solution is to 
disentangle this. E.g. introduce a new method ::setModalTo(QWidget *), 
which if used overwrites to which parent a dialog is modal. (That is by 
default a dialog is modal to its parent, unless something else is set 
via setModalTo). This means code that uses modal widgets on the stack 
would need some conversion work, but that's as far as I can see the best 
solution.



The main benefits I see here that this scheme can co-exist with current
code, i.e. code bases could slowly opt-in and migrate step by step, and
it does not add the need to sprinkle user side code with the typical
smart pointer line noise.
The same is true for what I'm proposing. It can and does allow users to 
convert at they choosing, and since the vast majority of QObjects are 
created with parents, most QObjects will be created via makeChild. Using 
unique pointers is the exception not the norm with what I've proposed. 
And indeed due to the ergonomics of makeChild via make_unique, the user 
is steared towards using the better way to construct QObjects.


Now, what André is proposing is very similar to just having a owning 
smart pointer that remembers the pointed at object after it has lost 
ownership. I see no reason why that (or more fuller proxy classes) 
couldn't work. But,


* The class/smart pointer would need to be move only, which limits how 
useful it is.

* The semantics feel strange to me.

And while I'd encourage someone to try it out, I'm of the firm opinion 
that Qt should try to get over its NIH attitude. One of the issues with 
Qt in the real world is that it's just that tiny bit differently than 
what non Qt C++ users are familiar with for. Sometimes that's for a good 
reason. but there's a cost there that is imho unappreciated inside the 
Qt bubble.


Also nowadays C++ is changing quite fast and the way to profit from the 
advancements in standard c++ is by making sure that Qt works great with 
new standard c++ idioms. It's not by investing time into inventing a 
slightly different idiom.


For example, Microsoft is still researching whether static analysers 
could detect dangling pointers [2]. That tool obviously will understand 
unique_ptr and is unlikely to understand our custom solution.


daniel

[1] 

Re: [Development] Be careful with duplicate Change-Ids in multiple branches in gerrit

[Oswald Buddenhagen]

On Tue, May 07, 2019 at 01:52:48PM +, Liang Qi wrote:
> This is a very common issue when I do the integraton work in qt5.
> 
> For example, currently we have 5.12->5.13->dev merge order, and the last 
> round 5.13->5.13.0 today. One change(changeA) had been integrated in 5.13, 
> and another change(changeB) with duplicate Change-Id was pushed to 5.13.0 
> branch with status:open. When I try to merge 5.13 to 5.13.0, the changeB will 
> be picked up by gerrit and be part of the integration, which I found in COIN. 
> Normally that integation will fail, but I am not 100% sure.
> 
> I only know the phenomenon, but not the root cause.
> 
> If you have a change was merged in lower branch, please try to avoid use 
> duplicate Change-Id in upper branch, at least in the current merge order.
> 
please don't give such bad advice.

firstly, the issue occurs only if neither change was integrated yet.
i've yet to see actual evidence of another case.
and yes, that's a bug in the gerrit CI customization. one can only hope
that The Upgrade will fix it.

secondly, if you're doing a cherry-pick which will be followed by a
merge, _then you're doing it wrong_. most commonly, that will be the
effect of client-side re-targeting where the original change was not
abandoned.

> If you have a change landed in 5.12, and it's ok to have duplicate Change-Id 
> when you cherry-picked it to 5.9, because we don't do merge from 5.9 to 5.12.
> 
> Best Regards,
> Liang
> ___
> 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] Gerrit Upgrade

[Giuseppe D'Angelo via Development]

Il 06/05/19 14:16, Frederik Gladhorn ha scritto:

We will collect some documentation here, currently it's just a placeholder
page, not yet worth visiting, unless you know the newer Gerrit and want to
help out documenting what is new:
https://wiki.qt.io/Gerrit_Upgrade_2019


Wow, this is a very welcome upgrade :)

Thank you so much!

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

[Development] HEADS-UP: Branching from '5.13' -> '5.13.0' completed

[Jani Heikkinen]

Hi all,

Branching from '5.13' -> '5.13.0' is now done. So from now on all changes to Qt 
5.13.0 release must be done in '5.13.0' and '5.13' is for Qt 5.13.1. And as 
usual no any nice-to-haves in '5.13.0' anymore; just a fixes for release 
blockers (and documentation improvements as well). And as usual staging in 
'5.13.0' is restricted for Qt Release team only and we will monitor incoming 
changes automatically & stage clear ones in automatically. 

br,
Jani 

> -Original Message-
> From: Development  On Behalf Of
> Jani Heikkinen
> Sent: tiistai 30. huhtikuuta 2019 7.19
> To: development@qt-project.org; releas...@qt-project.org
> Subject: [Development] HEADS-UP: Branching from '5.13' -> '5.13.0' started
> 
> Hi all,
> 
> We have soft branched '5.13.0' from '5.13'. So please start using '5.13.0' for
> new changes targeted to Qt 5.13.0 release. Final downmerge from '5.13' to
> '5.13.0' will happen Monday 6th May so there is enough time to finalize
> ongoing changes in '5.13'.
> 
> br,
> Jani Heikkinen
> Release Manager
> ___
> 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] unique_ptr and Qt, Take 2

[Konstantin Tokarev]

>> Can you explain what you mean with “understands the parent/child-ownership 
>> model”?
>>
>> Are you suggesting a unique_ptr-like template class that doesn’t destroy the 
>> object in its destructor if that object still has a parent?
>
> It could be something like that. One option could be to behave like a 
> unique_ptr if the object doesn’t have a parent, and like a weak pointer 
> otherwise. One would have to try it out though, to see whether that would 
> give semantics that are intuitive and feel right to users.

Intuitive behavior would be to behave like weak pointer if object has a parent 
and is a direct class member of its parent object, otherwise behave like a 
unique_ptr.


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

Re: [Development] unique_ptr and Qt, Take 2

[Lars Knoll]

On 7 May 2019, at 15:00, Volker Hilsheimer 
mailto:volker.hilshei...@qt.io>> wrote:

On 6 May 2019, at 22:20, Lars Knoll mailto:lars.kn...@qt.io>> 
wrote:
On 6 May 2019, at 20:23, André Pönitz 
mailto:apoen...@t-online.de>> wrote:

On Mon, May 06, 2019 at 07:41:05AM +, Lars Knoll wrote:
On 6 May 2019, at 09:30, Christian Kandeler
mailto:christian.kande...@qt.io>> wrote:

On Sat, 04 May 2019 09:06:39 +0200 Allan Sandfeld Jensen
mailto:k...@carewolf.com>> wrote:

On Samstag, 4. Mai 2019 00:43:10 CEST Thiago Macieira wrote:
On Friday, 3 May 2019 13:00:52 PDT Иван Комиссаров wrote:
Which should be considered bad practice and banned on an API
level

No way.

Are you going to forbid creation of QFile on the stack?

Perhaps QFile shouldn't be the same kind of base object type as
QWidgets? Or not use the same smart pointer.

Though even making QWidgets not allowed on the stack, while
sensible, would break a many of our tests, where we "abuse" that it
is technically possible in simple cases.

Doesn't almost every project create its main widget on the stack?

Not sure whether it’s most projects, but there certainly are users
doing it. And we’ve been using the pattern in our examples in some
cases as well. But I can relate to Allan that creating widgets on the
stack is bad style (as it conflicts with the way we memory manage
them), and if I’d have a choice today, I would probably prefer to
enforce them to be created on the heap by some means.

I wonder whether there's a solution in the following direction:

Have something like the following for each QObject derived class Foo
(for which it makes sense. E.g. perhaps all widgets, but not QFile):

[…]

The main benefits I see here that this scheme can co-exist with current
code, i.e. code bases could slowly opt-in and migrate step by step, and
it does not add the need to sprinkle user side code with the typical
smart pointer line noise.

Interesting idea. I sometimes thought that if we’d be creating Qt from scratch, 
one could make it all value based and have the objects on the heap hidden 
behind it. This would give something similar. As an added benefit, we could 
probably allocate the object and it’s private in one go without requiring the 
TLS hacks that https://codereview.qt-project.org/#/c/165445/ uses.

This could maybe bet combined with a custom template class handling our 
pointers (instead of unique_ptr) that understands the parent/child ownership 
model, plus typedefs for the different QObject based classes in the Qt 
namespace.


Can you explain what you mean with “understands the parent/child-ownership 
model”?

Are you suggesting a unique_ptr-like template class that doesn’t destroy the 
object in its destructor if that object still has a parent?

It could be something like that. One option could be to behave like a 
unique_ptr if the object doesn’t have a parent, and like a weak pointer 
otherwise. One would have to try it out though, to see whether that would give 
semantics that are intuitive and feel right to users.

Cheers,
Lars



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

[Development] Be careful with duplicate Change-Ids in multiple branches in gerrit

[Liang Qi]

This is a very common issue when I do the integraton work in qt5.

For example, currently we have 5.12->5.13->dev merge order, and the last round 
5.13->5.13.0 today. One change(changeA) had been integrated in 5.13, and 
another change(changeB) with duplicate Change-Id was pushed to 5.13.0 branch 
with status:open. When I try to merge 5.13 to 5.13.0, the changeB will be 
picked up by gerrit and be part of the integration, which I found in COIN. 
Normally that integation will fail, but I am not 100% sure.

I only know the phenomenon, but not the root cause.

If you have a change was merged in lower branch, please try to avoid use 
duplicate Change-Id in upper branch, at least in the current merge order.

If you have a change landed in 5.12, and it's ok to have duplicate Change-Id 
when you cherry-picked it to 5.9, because we don't do merge from 5.9 to 5.12.

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

Re: [Development] unique_ptr and Qt, Take 2

[Volker Hilsheimer]

On 6 May 2019, at 22:20, Lars Knoll mailto:lars.kn...@qt.io>> 
wrote:
On 6 May 2019, at 20:23, André Pönitz 
mailto:apoen...@t-online.de>> wrote:

On Mon, May 06, 2019 at 07:41:05AM +, Lars Knoll wrote:
On 6 May 2019, at 09:30, Christian Kandeler
mailto:christian.kande...@qt.io>> wrote:

On Sat, 04 May 2019 09:06:39 +0200 Allan Sandfeld Jensen
mailto:k...@carewolf.com>> wrote:

On Samstag, 4. Mai 2019 00:43:10 CEST Thiago Macieira wrote:
On Friday, 3 May 2019 13:00:52 PDT Иван Комиссаров wrote:
Which should be considered bad practice and banned on an API
level

No way.

Are you going to forbid creation of QFile on the stack?

Perhaps QFile shouldn't be the same kind of base object type as
QWidgets? Or not use the same smart pointer.

Though even making QWidgets not allowed on the stack, while
sensible, would break a many of our tests, where we "abuse" that it
is technically possible in simple cases.

Doesn't almost every project create its main widget on the stack?

Not sure whether it’s most projects, but there certainly are users
doing it. And we’ve been using the pattern in our examples in some
cases as well. But I can relate to Allan that creating widgets on the
stack is bad style (as it conflicts with the way we memory manage
them), and if I’d have a choice today, I would probably prefer to
enforce them to be created on the heap by some means.

I wonder whether there's a solution in the following direction:

Have something like the following for each QObject derived class Foo
(for which it makes sense. E.g. perhaps all widgets, but not QFile):

[…]

The main benefits I see here that this scheme can co-exist with current
code, i.e. code bases could slowly opt-in and migrate step by step, and
it does not add the need to sprinkle user side code with the typical
smart pointer line noise.

Interesting idea. I sometimes thought that if we’d be creating Qt from scratch, 
one could make it all value based and have the objects on the heap hidden 
behind it. This would give something similar. As an added benefit, we could 
probably allocate the object and it’s private in one go without requiring the 
TLS hacks that https://codereview.qt-project.org/#/c/165445/ uses.

This could maybe bet combined with a custom template class handling our 
pointers (instead of unique_ptr) that understands the parent/child ownership 
model, plus typedefs for the different QObject based classes in the Qt 
namespace.


Can you explain what you mean with “understands the parent/child-ownership 
model”?

Are you suggesting a unique_ptr-like template class that doesn’t destroy the 
object in its destructor if that object still has a parent?


Volker

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

Re: [Development] Gerrit Upgrade

[Jukka Jokiniva]

The new Gerrit version will use Polymer-based UI, the "old style UI" will be 
disabled.

If someone want to see the new UI in action, the Gerrit code is reviewed in 
Gerrit: https://gerrit-review.googlesource.com/
Just a note that the site is using the very latest 3.0 RC, and we will be using 
2.16.7, but the UI is pretty much the same.

--Jukka

On 06/05/2019, 22.54, "Development on behalf of Konstantin Tokarev" 
 wrote:

Are we planning to use Polymer-based UI, as currently used by Chromium and 
Android,
or the "old" one (which is probably still a default)? I believe "old" one 
has a horrible UX,
while Polymer one is a bit nicer. Also, Polymer's patch viewer plays nicely 
with X selection
buffer, while "old" does not.

06.05.2019, 15:18, "Frederik Gladhorn" :
> Hello,
>
> We've been working on the Gerrit Upgrade for a while now and we are 
finally
> getting ready to deploy the new goodness.
>
 

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

Re: [Development] Gerrit Upgrade

[Alexandru Croitor]

I hope you have at least two backups in two different locations. : )

> On 7. May 2019, at 11:02, Jukka Jokiniva  wrote:
> 
> 
> On 06/05/2019, 22.46, "Development on behalf of Sergio Ahumada" 
>  wrote:
>> 
>>   On 06.05.19 14:16, Frederik Gladhorn wrote:
>>> We aim to do the Upgrade to Gerrit 2.16.7 around the 20th of May (yes, 
>>> that's
>>> a Monday, we assume Gerrit will be down for the full day that day).
>> 
>>   Did you already try migrating the repos from the old Gerrit to the new
>>   one? Is that why it would take the whole day?
>> 
>>   If so, did you have to migrate step by step 2.7->2.8->...->2.15->2.16 or
>>   directly from 2.7->2.16?
> 
> Yes, we have been testing the data migration from old Gerrit to the new 
> version couple of times.
> We need to migrate step by step, some versions we can skip but there are 
> seven versions to be installed.
> 
> Installing the versions takes about one hour and complete reindex of the data 
> about 2 hours. Then there are other steps to do as well.
> So if things go smoothly the minimum down time is around 4 hours. But no 
> promises, be prepared that the tool is offline the whole day.
> 
>   --Jukka
> 
> 
> ___
> 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] Gerrit Upgrade

[Jukka Jokiniva]

On 06/05/2019, 22.46, "Development on behalf of Sergio Ahumada" 
 wrote:
>
>On 06.05.19 14:16, Frederik Gladhorn wrote:
>> We aim to do the Upgrade to Gerrit 2.16.7 around the 20th of May (yes, 
> that's
>> a Monday, we assume Gerrit will be down for the full day that day).
>
>Did you already try migrating the repos from the old Gerrit to the new
>one? Is that why it would take the whole day?
>
>If so, did you have to migrate step by step 2.7->2.8->...->2.15->2.16 or
>directly from 2.7->2.16?

Yes, we have been testing the data migration from old Gerrit to the new version 
couple of times.
We need to migrate step by step, some versions we can skip but there are seven 
versions to be installed.

Installing the versions takes about one hour and complete reindex of the data 
about 2 hours. Then there are other steps to do as well.
So if things go smoothly the minimum down time is around 4 hours. But no 
promises, be prepared that the tool is offline the whole day.

   --Jukka


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