Important note :
In this answer I use freely the terminology "static"
and "dynamic" to refer, respectively, to the allocation of data in the
stack and not heap . I call the stack allocation "static"
because it is somewhat immutable (it is done early in the program), and the
allocation in the heap of "dynamic" because the control is more directly
in the programmer's hand.
@bigown colleague, for example, commented very well the following to
this respect:
"I use a different terminology, for me static allocation is that
previously done and is valid for the entire execution of the
no need to allocate. The allocation in the stack, appending the name induce to be
something static by similarity, it is not a static allocation, it is
automatically. The allocation of the entire stack is static, but not your
objects. I think the terminology used is wrong and gives a
misunderstanding, at least for anyone who understands the subject. For who
do not understand will understand until, but the wrong. So the confusion. "
And your colleague @ José X. also commented very well about this:
"This subject goes a long way ... take a look at here and here (the
text of the OS points to the Wikipedia link). I just wanted to give one more
example: a non-static and non-pointer member of a class that is
instantiated in the heap ... although it is not a pointer, this member in the
truth is allocated in the heap, not the stack. "
Indeed, perhaps the term "automatic allocation" is more appropriate
to avoid confusion. I made that observation because I thought she was
important, although the focus of the answer was not necessarily this.
Objects statically allocated (that is, on the stack) exist in the scope in which they were created. When this scope expires, they are automatically removed by the compiler. So, in your code ...
void MyClass::functionExample(){
AnotherClass obj;
obj.setData(1);
}
... the obj instance will only exist within the functionExample method. When this method finishes, this instance will be automatically deleted (and the destructor, if it exists, will be invoked).
Unlike previous ones, objects dynamically allocated (that is, in the heap) exist until they are explicitly destroyed (by the programmer, in general). When memory is often allocated in the heap and is not freed by error, memory leak occurs ( memory leak ), which causes even a gradual reduction of system performance by excessive use of resources (though not the only potential cause of poor performance).
So, in your code ...
void MyClass::functionExample(){
AnotherClass *obj = new AnotherClass();
obj->setData(1);
}
There is a memory leak. The obj variable is a pointer to an instance of AnotherClass . It alone is a statically allocated variable (in the stack - do not confuse with a variable declared static), and therefore exists only within the scope of the functionExample method. Using the new operator, you create a new instance of AnotherClass (allocating memory for it) and stores the address of that memory in the obj variable. When the functionExample method is terminated, this variable is deleted, and since you no longer have the reference of the address that was allocated, you no longer have to release that memory that remains "lost" in the heap until the whole program finishes. >
Note that Qt has some features for automatically managing the memory of objects inherited from QObject . When you create a widget, for example, you can enter as a parameter the pointer to an instance of another widget ( QWidget* ) that will be the "parent" of that widget. This parent object will automatically destroy all your children when it is itself deleted.
I do not know if this was the case, since you did not mention, that your class AnotherClass inherits from QObject , but even if it were the leak still exists because you did not pass this parameter (usually this to indicate that the current object is the parent of the one being created).
