Pro and cons about creating QObjects components on the stack instead of creating them dynamically.
-
@JonB Right, the last one thing, why should I set a parent to a stacked QObject if I don't want that qt manages memory for it?
I mean, if I never set a parent for stacked qobject the order of the objects creation doesn't matter because they aren't in the qt object tree. I am right or not? ThanksIn addition to what @JonB wrote, the object trees are not exclusively for memory management. The widgets use the parent as a visual parent as well, and to distinguish between needing to be an alien or a native widget.
-
wrote on 15 Apr 2020, 06:19 last edited by
@Jimmy-Loyola said in Pro and cons about creating QObjects components on the stack instead of creating them dynamically.:
I mean, if I never set a parent for stacked qobject the order of the objects creation doesn't matter because they aren't in the qt object tree. I am right or not? Thanks
If you were to really do that, then you are fine. However, there is a slightly non-obvious way of setting a parent: When you put a widget into a layout it is re-parented. (And so its lifetime is again managed by Qt.) Basically the best rule you can have is that in general widgets should live on the heap. There are very few exceptions for this: 1) The MainWindow created in
maincan live on the stack (it does not have a parent). 2) A modal dialog can usually be constructed on the stack.As mentioned before, all the other non-widget class, e.g.
QFile, can be managed without parents and thus are allowed to live on the stack. -
@Jimmy-Loyola said in Pro and cons about creating QObjects components on the stack instead of creating them dynamically.:
I mean, if I never set a parent for stacked qobject the order of the objects creation doesn't matter because they aren't in the qt object tree. I am right or not? Thanks
If you were to really do that, then you are fine. However, there is a slightly non-obvious way of setting a parent: When you put a widget into a layout it is re-parented. (And so its lifetime is again managed by Qt.) Basically the best rule you can have is that in general widgets should live on the heap. There are very few exceptions for this: 1) The MainWindow created in
maincan live on the stack (it does not have a parent). 2) A modal dialog can usually be constructed on the stack.As mentioned before, all the other non-widget class, e.g.
QFile, can be managed without parents and thus are allowed to live on the stack.@SimonSchroeder said in Pro and cons about creating QObjects components on the stack instead of creating them dynamically.:
Basically the best rule you can have is that in general widgets should live on the heap.
Why do you do this to me? I just spent 2 days and about 7 posts to show there's no such rule. If there's such a recommendation even, that is to avoid putting objects in the stack, in the Qt documentation please point me to it.
-
wrote on 16 Apr 2020, 06:24 last edited by
@kshegunov said in Pro and cons about creating QObjects components on the stack instead of creating them dynamically.:
Why do you do this to me? I just spent 2 days and about 7 posts to show there's no such rule. If there's such a recommendation even, that is to avoid putting objects in the stack, in the Qt documentation please point me to it.
You are right that it is nowhere written in the Qt documentation. And this is only a rule of thumb. As you have showed it is possible to put them on the stack. However, in most cases you do not have widgets living inside the scope of a function. In many cases I construct widgets inside the constructor of another widget's class. (Right now, I don't even use member variables because the parent tree will take care of everything.) In this case I would need a bunch of member variables inside the class. These would need to be in the right order inside the class declaration already (because they are initialized in that order). I think it is hard to add just another widget in the right place in this list of members (and beware if you forget to think about it only once). BTW, I am not even entirely sure how the widget will be re-parented when added to a layout. Is it reparented to the layout or the widget that the layout belongs to?
In short: If you put your widgets on the heap and you are consistently using layouts, you don't have to think about anything at all. You don't even have to think about setting parents. If, on the other hand, you are putting your widgets on the stack you always have to take care of the order of variable declarations. You need to think about two things at the same time: The look of your UI and memory management/stack layout. Adding a new widget to the layout is harder because you need to find the right place to declare it. Moving a widget to another place in your layout could mean to move its declaration as well if you are using sublayouts.
To me, it is much harder to reason about widgets on the stack. And it certainly is not beginner-friendly. It might even become a maintenaince nightmare. I usually try to use approaches that have the least chance of accidental errors. That is why I usually put everything I can on the stack. Then I get free lifetime management. The Qt parent tree also manages lifetime. Having two competing lifetime managers is just too error prone. I don't want to fight Qt's lifetime manager, but rather be friends with it.
The only reason left to not put widgets on the heap would be speed.
newanddeleteare notoriously slow. Nevertheless, we are talking about the GUI here and thus only have to match human speed. I have rarely seen a performance problem with creating layouted widgets fully on the heap. So, as long as you don't have a performance problem don't optimize prematurely.Basically, what it comes down to why I am proposing allocation of widgets on the heap as a rule of thumb is 1) maintainability and 2) saving hours of debugging mysterious errors.
21/24