Why some QT elements can be created as local and lives outside?

This is a question that I have from time to time.
In example, the analog clock example shows how you can create a Qtimer object inside analog_clock constructor and it lives until you close the app.
The question, 'Why I have the impression that I see (somtimes) at Qt examples, objects that needs to be pointer based, created and deleted and some times I see objects created as 'locals' inside a method (and they works fine during the life of the prog..'
Or Maybe I see this always at constructor and in this case they have a singular treatment ?

I hope you understand this doubt.

Thanks.

Quote:

---

Originally Posted by tonnot

This is a question that I have from time to time.
In example, the analog clock example shows how you can create a Qtimer object inside analog_clock constructor and it lives until you close the app.
The question, 'Why I have the impression that I see (somtimes) at Qt examples, objects that needs to be pointer based, created and deleted and some times I see objects created as 'locals' inside a method (and they works fine during the life of the prog..'
Or Maybe I see this always at constructor and in this case they have a singular treatment ?

---

The analog clock example creates a QTimer on the heap. The pointer to that object is a local, not the object itself. The pointer is discarded at the end of the constructor and is no longer available to locate the QTimer object. The object on the heap persists until delete is called on it. The author of the example has used the QObject ownership mechanisms to ensure this QTimer object is deleted at the time the AnalogClock object that created it is deleted.

To use a non-computing analogy: I give you and another person each a piece of paper with the address of a new house. If you throw away your piece of paper you can no longer find the house but the house continues to exist. The other person can still find the house and can come around later to demolish it.

In short: You use heap created objects when they must survive outside the scope in which you create them, and stack-based/local objects the remainder of the time. You are responsible for ensuring the heap-based object is deleted by some mechanism.

Hi tonnot,

in addition to what Chris explained: "pointer vs. local variables" or "creating objects on the heap vs. on the stack" is basic c++ and generally not Qt-related.

I suggest to use smart pointers for handling pointers. In the "house"-example of chris, I would use a boost::shared_ptr<house>. This type of smart pointer tracks the number of references to the stored object. In the example, the counter would be 2. When the first person throws away its paper, the counter decreases to 1. When the last adress paper gets thrown away, the counter decreaes to zero which automatically destroys the house. This avoids memory leaks.

I assume, Qt offers some smart pointers, too. But I never used them (besides of QPointer), so I can't tell you details about that.

Felix

If you use it, like the referenced example does, then the QObject parenting system looks after deletion in the case of heap allocated QObjects and QWidgets. For other objects there are QScopedPointer, QSharedPointer and a few other variations in the Qt arsenal, but boost::shared_ptr and std::tr1::shared_ptr work also.