What do you prefer: dynamically or statically create objects?

Until I begun to work with QT, I always prefered to create objects statically (ie not a pointer filled with new), so that I don't forget to call delete.

With the QT tree object model, you only have to care about the top level widgets so the risk of memory leaks is lowered. QT seems to enforce the creation of objects dinamically (in their examples and in designer generated code).

What is the criterium followed by you in order to use either allocation model?

Allocating on the heap or stack is just like any other tool - use it when the it fits your problem needs.
There is no absolute right and wrong.
You can't use stack allocation for conditional allocations for example.
Unless you allocate everything in advance and use only what you need later.
But that is bad practice.
Some applications need a lot of memory, and usually stacks are limmited.
There many situations where one is better then the other.
The buttom line is - it depends on the current situation you need to allocate for.

But for example, in a lot of QT examples the widgets are created dinamically, and they last to the end of program life, so at a first glance they could be created statically. As you said there are times when you have to use heap allocation, so my strategy until now was to allocate everything that lives til the end of program statically, and only resort to heap allocation when needed.

As QT examples seem to use heap allocation for all widgets, independently of their scope, I thought there could be some reason for creating them dinamically.

There is a reason or it's just a matter of taste?

Quote:

---

so my strategy until now was to allocate everything that lives til the end of program statically

---

But you are using the wrong assumption.
Stack allocated memory lives in the scope it is created.
so if you create a variable on the stack inside a function for example, at the end of the function this variable will be deleted.
If you use only objects that are allocated on the stack, it will be very dengerous for you to use pointers, since you can never know if the address of the object your pointer points to is till alive, since you can never be sure if the probgram exited the scope in which it is allocated.
You can "escape" with it to some degree by declering all your used variables as calss members and allocating them on stack, but it really is a very restrictive way to wrok, and unsafe.
Actually the only way for you to know that an object will live for the duration of the application is by allocating it on the heap.

Quote:

---

Originally Posted by IrYoKu

There is a reason or it's just a matter of taste?

---

Yes, there is a reason. You can't allocate a widget that has a parent on the stack unless you make sure the child is destroyed before the parent. Otherwise the parent will delete the child and then the compiler will try to delete it again when going out of scope and the application will crash.

Besides, some systems have a very short stack, so you shouldn't waste it for widgets.

Quote:

---

Originally Posted by high_flyer

But you are using the wrong assumption.
Stack allocated memory lives in the scope it is created.

---

I meant declaring them as class members. If they live during all class life, I didn't see the problem of being statically allocated.

Quote:

---

Originally Posted by wysota

Yes, there is a reason. You can't allocate a widget that has a parent on the stack unless you make sure the child is destroyed before the parent. Otherwise the parent will delete the child and then the compiler will try to delete it again when going out of scope and the application will crash.

---

But if it's a statically allocated widget, it doesn't need to be created with a parent, right?

Anyway, the point of the stack being limited is enough to allocate widgets on the heap.

Thanks to both by your replies :)

Quote:

---

Originally Posted by IrYoKu

But if it's a statically allocated widget, it doesn't need to be created with a parent, right?

---

If you want a widget to do anything usefull, it'll have to have children (which means its children will have to have a parent). Otherwise you'll end up with a bunch of empty top-level (stack allocated) windows that do nothing.

Also consider the fact, that behind the scenes each QObject consists of two parts - the part that exposes the API and a private component that is always allocated on heap. So you're using heap even if you never explicitely used operator new.

Quote:

---

Originally Posted by wysota

If you want a widget to do anything usefull, it'll have to have children (which means its children will have to have a parent). Otherwise you'll end up with a bunch of empty top-level (stack allocated) windows that do nothing.

---

AFAIK, you can add wigets without parent into QLayout objects, and they convert from top level windows into normal widgets. So you the same result can be achieved with both static and dynamic allocation strategies.

Quote:

---

Originally Posted by wysota

Also consider the fact, that behind the scenes each QObject consists of two parts - the part that exposes the API and a private component that is always allocated on heap. So you're using heap even if you never explicitely used operator new.

---

It's not like I don't want to use the heap. As I said before, I used the stack til now because this way I never forget to delete. But with QT tree deletion features, this don't worrie me anymore.

Quote:

---

Originally Posted by IrYoKu

AFAIK, you can add wigets without parent into QLayout objects, and they convert from top level windows into normal widgets.

---

...by reparenting the widget (see the attached example).

Edit: And another example:

Code:

---

#include <QApplication>
#include <QWidget>
 
int main(int argc, char **argv){
  QApplication app(argc, argv);
//  QWidget c1;
  QWidget top;
  QWidget c1;
  c1.setParent(&top);
  return 0;
}

---

Try running this app and then run it again after uncommenting 6th and commenting the 8th line of this snippet. Compare results.