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

[Jimmy Loyola]

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?

[kshegunov]

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

[jsulm]

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

[Jimmy Loyola]

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

[JonB]

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

[kshegunov]

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

[kshegunov]

@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());

[JonB]

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

[kshegunov]

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

[JonB]

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

[Jimmy Loyola]

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

[kshegunov]

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

[Jimmy Loyola]

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

[Jimmy Loyola]

@kshegunov Doesn't Dummy class have a constructor?

[Jimmy Loyola]

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

[kshegunov]

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

[Jimmy Loyola]

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

[JonB]

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

[kshegunov]

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

[Jimmy Loyola]

@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

[JonB]

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