Important: Please read the Qt Code of Conduct - https://forum.qt.io/topic/113070/qt-code-of-conduct

Pro and cons about creating QObjects components on the stack instead of creating them dynamically.



  • Are there any kind of problem if I allocate QObjects on the stack to avoid problem about memory management? Should I prefer dynamic allocated QObjects and delegate memory managament by qt object trees and its ownership system?


  • Qt Champions 2017

    @Jimmy-Loyola said in Pro and cons about creating QObjects components on the stack instead of creating them dynamically.:

    its a little bit unusual listening about that heap allocation is more secure than stack allocation for memory management. But if this is the qt philosophy we must follow it.

    I didn't say that, in fact I argued that both are valid approaches. As you can leak or double-delete a heap object, so you can double delete a stack object, it's just a fact of life. In any case Qt allows you both gracefully, so it's up to your preference which you're going to use. Me personally, I'm a stack-lover, I always put things in the stack if I can help it. It usually looks something like this:

    class Dummy : public QObject
    {
    public:
        using QObject::QObject;
    };
    
    class DummyParent : public QObject
    {
    public:
        DummyParent(QObject * parent = nullptr)
            : QObject(parent), owned(this)
        {
        }
    
        Dummy owned;
    };
    

    This construct is a FILO (i.e. stack) by itself, so it works gloriously without an issue.


  • Lifetime Qt Champion

    @Jimmy-Loyola said in Pro and cons about creating QObjects components on the stack instead of creating them dynamically.:

    Are there any kind of problem if I allocate QObjects on the stack to avoid problem about memory management?

    Yes, you can cause double delete. Stack allocated objects are deleted as soon as they go out of scope. In case of QObject derived classes such object can have a parent. Parent deletes its children when it is deleted. But if the child was already deleted (because it went out of scope) parent would try to delete already deleted object. So, for QObject based objects it is better to stick with Qt object trees. But not always. For example it is perfectly fine to create a QFile object on the stack as long as you do not give it a parent.



  • @jsulm Thanks, which is the best approach in the qt environment to prevent leaks caused by a dynamic allocated qobject without ownership before it has assigned to a father.

    ...
    toolbar = new QToolBar; // has no ownership
    ...
    // something goes wrong and exit from the scope
    return; // leak caused by toolbar
    ...
    addToolBar(toolbar);
    ...
    


  • @Jimmy-Loyola
    I'm going to throw my answer out there, ready to be shot down....

    If you really do feel you need to do this (automatically, without doing you own explicit delete), I would go:

    ...
    QWidget tempStackWidget;  // temporary QWidget on the function's stack
    toolbar = new QToolBar(&tempStackWidget); // now does have ownership, right from the start
    ...
    // something goes wrong and exit from the scope
    return; // tempStackWidget goes out of scope, taking new QToolbar with it
    ...
    addToolBar(toolbar); // new QToolbar moves from tempStackWidget to QMainWindow, so not destroyed
    ...
    

  • Qt Champions 2017

    @jsulm said in Pro and cons about creating QObjects components on the stack instead of creating them dynamically.:

    @Jimmy-Loyola said in Pro and cons about creating QObjects components on the stack instead of creating them dynamically.:

    Are there any kind of problem if I allocate QObjects on the stack to avoid problem about memory management?

    Yes, you can cause double delete. Stack allocated objects are deleted as soon as they go out of scope. In case of QObject derived classes such object can have a parent. Parent deletes its children when it is deleted.

    This is true.

    But if the child was already deleted (because it went out of scope) parent would try to delete already deleted object.

    This is incorrect. When the child goes out of scope it notifies the parent, so that's not the problematic case. The problematic case is when the parent goes out of scope before the child does. Then it's going to try to free the children and thus cause a stack corruption.

    So, for QObject based objects it is better to stick with Qt object trees.

    The stack and object trees aren't mutually exclusive.

    But not always. For example it is perfectly fine to create a QFile object on the stack as long as you do not give it a parent.

    Giving it a parent is fine as long as it doesn't outlive the parent.


  • Qt Champions 2017

    @Jimmy-Loyola said in Pro and cons about creating QObjects components on the stack instead of creating them dynamically.:

    @jsulm Thanks, which is the best approach in the qt environment to prevent leaks caused by a dynamic allocated qobject without ownership before it has assigned to a father.

    The best way is to declare the ownership explicitly. Assuming that code resides in a QWidget:

    toolbar = new QToolBar(this);
    if (wrong)  {
        toolbar->deleteLater();
        toolbar = nullptr;
        return;
    }
    

    If this is in some outside class, you can do this:

    QScopedPointer<QToolBar> toolbar(new QToolBar());
    if (wrong)
        return;
    
    widget->addToolBar(toolbar.take());
    


  • @kshegunov
    You haven't commented on my sugegstion, which probably means you don't like it but are too kind to me to say so ;-)

    The question, as I read/think of it, is: Imagine I have a big function, with the new QToolbar at the top and lots of (potential) returns dotted all over the place, with the final addToolbar() near the end. I do not want to manually put in my own delete/deleteLater()s prior to the returns, because I'll make a mistake.

    In that case, wouldn't my suggestion of a "temporary stack-based parent till the addToolbar() call" be a simple way of ensuring a newed QToolbar gets deleted on function scope exit be acceptable?


  • Qt Champions 2017

    @JonB said in Pro and cons about creating QObjects components on the stack instead of creating them dynamically.:

    You haven't commented on my sugegstion, which probably means you don't like it but are too kind to me to say so ;-)

    I don't like it, I'm saying so.

    The question, as I read/think of it, is: Imagine I have a big function, with the new QToolbar at the top and lots of (potential) returns dotted all over the place. I do not want to manually put in my own delete/deleteLater()s prior to the returns, because I'll make a mistake.

    Yes, that's a valid concern. Then you'd use a scoped pointer so you make sure you own that object all the way until you actually add it to a container widget (i.e. a toolbar in this case)

    In that case, wouldn't my suggestion of a "temporary stack-based parent till the addToolbar() call" be a simple way of ensuring a newed QToolbar gets deleted on function scope exit be acceptable?

    Yes, although I'd avoid creating the heavy (compared to an owing pointer) machinery that is a widget just to ensure an object is deleted, hence me not liking it - it's an abuse of notation so to speak. There are better and "lighter" ways to do it, as I've mentioned.



  • @kshegunov Good stuff, point taken, thanks for letting me down gently ;-)



  • @kshegunov Thank you, its a little bit unusual listening about that heap allocation is more secure than stack allocation for memory management. But if this is the qt philosophy we must follow it.


  • Qt Champions 2017

    @Jimmy-Loyola said in Pro and cons about creating QObjects components on the stack instead of creating them dynamically.:

    its a little bit unusual listening about that heap allocation is more secure than stack allocation for memory management. But if this is the qt philosophy we must follow it.

    I didn't say that, in fact I argued that both are valid approaches. As you can leak or double-delete a heap object, so you can double delete a stack object, it's just a fact of life. In any case Qt allows you both gracefully, so it's up to your preference which you're going to use. Me personally, I'm a stack-lover, I always put things in the stack if I can help it. It usually looks something like this:

    class Dummy : public QObject
    {
    public:
        using QObject::QObject;
    };
    
    class DummyParent : public QObject
    {
    public:
        DummyParent(QObject * parent = nullptr)
            : QObject(parent), owned(this)
        {
        }
    
        Dummy owned;
    };
    

    This construct is a FILO (i.e. stack) by itself, so it works gloriously without an issue.



  • @JonB I liked your answer too much. I forgot to say that in some cases I could have objects that couldn't have a parent like a toolbar or other qt starndard objects. In that case I can't give them a temporary parent.



  • @kshegunov Doesn't Dummy class have a constructor?



  • @kshegunov I'm a stack-lover too so I'am traying to learn how to manage qt stacked objects properly. Could you link some good documentation about this topic? I would be glad. I see even qt recommend use dynamic memory to allocate gui objects but its docs doesn't specify how to deal with potential problems of this approach in a detailed way.


  • Qt Champions 2017

    @Jimmy-Loyola said in Pro and cons about creating QObjects components on the stack instead of creating them dynamically.:

    I'm a stack-lover too so I'am traying to learn how to manage qt stacked objects properly. Could you link some good documentation about this topic?

    Not currently, but I'll try to muster something this evening. In the mean time the major rule is - make sure the child is freed (by the stack) before the parent, this is enough. Also be wary of ownership transfer in Qt (it's noted in the docs).

    I would be glad. I see even qt recommend use dynamic memory to allocate gui objects but its docs doesn't specify how to deal with potential problems of this approach in a detailed way.

    I wouldn't go as far as to say it "recommends" it, but yes, it's more usual.



  • @kshegunov said in Pro and cons about creating QObjects components on the stack instead of creating them dynamically.:

    make sure the child is freed (by the stack) before the parent

    What do you thinkg about make sure the children are freed before their parents in the all application classes could require big efforts?



  • @Jimmy-Loyola
    @kshegunov is talking about "freed by the stack". That just means scope exit for local variables. So long as you add stack children after parent, not set parent on a child, this is the natural way function calls will arrange, is it not?


  • Qt Champions 2017

    @Jimmy-Loyola said in Pro and cons about creating QObjects components on the stack instead of creating them dynamically.:

    What do you thinkg about make sure the children are freed before their parents in the all application classes could require big efforts?

    Not really. If you stick to the "child is a member of parent object" (as I'd shown) you wouldn't have much trouble. Still caution is advised if objects are given to Qt for say to be inserted in a tab widget, because usually these containers take ownership of the object you pass them.

    @JonB said in Pro and cons about creating QObjects components on the stack instead of creating them dynamically.:

    @kshegunov is talking about "freed by the stack". That just means scope exit for local variables. So long as you add stack children after parent, not set parent on a child, this is the natural way function calls will arrange, is it not?

    Quite correct, yes. So like this:

    QObject parent(nullptr); // Root object, no parent
    QObject child1(&parent);
    QObject child2(&child1);
    

    By the natural way the stack is constructed you destroy them backwards, so you always destroy the children before the parent and you're perfectly fine. Compare with:

    QObject child1(nullptr); // Why no parent if it's a child
    QObject parent(nullptr); // First to go out of scope, the bells should be ringing in your ears already
    child.setParent(&parent); // Oh, no, no, I didn't mean to break the stack when we exit ...
    


  • @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? Thanks



  • @Jimmy-Loyola
    Yes, that in itself is true, if you have stack variables with no parentage it won't matter about destruction order.

    But as per @kshegunov code, in order to use these objects your code may have to set up parentage (or call Qt functions which implicitly do) as it goes along, and then the order will matter.


  • Qt Champions 2017

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



  • @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 main can 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.


  • Qt Champions 2017

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



  • @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. new and delete are 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.


Log in to reply