Important remark:
In this answer I use freely the term "static" allocation
and "dynamic" to refer respectively to the allocation of data in the
stack and no heap. I call stack allocation "static"
because it is kind of unchanging (it is done at the beginning of the program), and the
allocation in the heap of "dynamics" because the control is more directly
in the hand of the programmer.
For example, Mr @Maniero, commented very well the following to
that respect:
"I use a different terminology, for me static allocation is that
made in advance and valid for all the execution of the application, therefore
do not need to allocate. Stack allocation, append the name induce to be
something static by similarity, it is not a static allocation, it is
automatic. The allocation of the entire stack is static, but not its
objects. I think the terminology used is wrong and gives a
misconception, at least for those who understand the subject. For whom
does not understand will even understand, but the wrong. So the confusion."
And fellow @Jose X. also commented very well in that regard:
"This matter goes far... here and here (the
text from the OS points to the Wikipedia link). I just wanted to give one more
example: a non-Static and nonpointer member of a class that is
instantiated in the heap...
truth is allocated in heap, not stack."
Actually, perhaps the term "automatic allocation" is more appropriate
to avoid confusion. I made this observation because I thought she was
important, although the focus of the answer was not that necessarily.
Statically allocated objects (i.e., in the stack) exist in the scope in which they were created. When this scope ends, they are automatically removed by the compiler. Thus, in your code...
void MyClass::functionExample(){
AnotherClass obj;
obj.setData(1);
}
...the instance of obj will exist only within the method functionExample. When this method is finished, this instance will be deleted automatically (and the destructor, if it exists, will be invoked).
Unlike the previous ones, dynamically allocated objects (i.e., in the heap) exist until they are explicitly destroyed (by the programmer in general). When memory is allocated many times in heap and is not released by error, it occurs what is called memory leakage (memory Leak), which causes even a gradual reduction in the performance of the system by the excessive use of resources (although it is 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 variable obj is a pointer to an instance of AnotherClass. It, by itself, is a statically allocated variable (in the stack - do not confuse with a variable declared as static) and therefore exists only within the scope of the method functionExample. Using the operator new, you create a new instance of AnotherClass (allocating memory for such) and saves the address of that memory in the variable obj. When the method functionExample ends, this variable is deleted, and since you no longer have the address reference that was allocated you no longer have a way to release that memory that remains "lost" in the heap until the entire program is finished.
Note that Qt has some features to automatically manage the memory of objects inherited from QObject. When you create a widget, for example, you can specify as a parameter the pointer to an instance of another widget (QWidget*) that will be the "father" of that object. That parent object will automatically destroy all your children when it is itself eliminated.
I don’t know if that was the case, since you didn’t quote from your class AnotherClass inherit from QObject, but even if it was the leak still exists because you did not pass such parameter (usually this to indicate that the actual object is the father of the one being created).
The ideal is not to use delete, is to play the pointer inside a "smart Pointer". My last major C++ project scanned the use of "delete" and wouldn’t build it if it found a.
– epx