[Solved] When does an object need to be a pointer

terietor

Hello,

the first code snippet works correctly but the second doesn't.

The first one is the one which is commented out.

@qapplications::qapplications()//inherits QMainwindow class
{
/* QLabel* l = new QLabel( this );
l->setText( "Hello World!" );
setCentralWidget( l );
QAction* a = new QAction(this);
a->setText( "Quit" );
connect(a, SIGNAL(triggered()), SLOT(close()) );
menuBar()->addMenu( "File" )->addAction( a );*/

QLabel l;
l.setText( "Hello World!" );
setCentralWidget( &l );
QAction a(this);
a.setText( "Quit" );
connect(&a, SIGNAL(triggered()), SLOT(close()) );
menuBar()->addMenu( "File" )->addAction( &a );

}@

This is my actual question,when does an object need to be a pointer and when it doesn't?
Can you point me in some detail documentation?

thanks in advance

loladiro

A pointer is not destroyed at the end of a function. A variable that is created on the stack is.
This can have advantages and disadvantages.
Couple of things to note:

When creating a variable as a pointer (i.e. on the heap) you need to delete it using
@ delete myPointer; @
This is done automatically by Qt if the Object has a parent,
If you don't do it you will create a memory leak (i.e. your application blocks memory that's not used)
As I said, when creating the variable on the stack, they are destroyed (go out of scope) at the end of the function. This is the reason why your second example doesn't work. They cease to exist at the end of the function.

terietor

thanks

In this situation,QMainwindows and QLabel have a parent so they will be deleted by Qt.Only the QAction doesn't have one.
Correct?

Also can you explain to me the terms stack and heap.I know that they are the list of code,but what are they specifically?

loladiro

The parent is whatever to your pass to the constructor.
E.g.
@
QLabel *label = new QLabel(this)
@
will be destroyed when the MainWindow is destroyed
@
QLabel *label = new QLabel;
@
will not be destroyed and create a memory leak if you don't delete id manually.

On the question about heap and stack, I will refer you to "this tutorial":http://www.learncpp.com/cpp-tutorial/79-the-stack-and-the-heap/

terietor

In the Qt api when i see

@QPushButton ( QWidget * parent = 0 )@

this means that i have an invalid parent.Correct?
But why Qt is made like that?

(thanks again)

loladiro

In that that case the object doesn't have a parent and will not be deleted.
It's done that way so you can easily create top-level widgets. Those widgets are usually declared in main() and it therefore doesn't matter if those widgets are destroyed at the end of main() (because the application is done anyway).

terietor

thank you for your help

How can i mark this thread as solved?

loladiro

Just edit the first post and add [Solved] in front of the title (A proper implementation for doing this is being worked on).

terietor

thanks again :)

goetz

[quote author="loladiro" date="1313076273"]A pointer is not destroyed at the end of a function. A variable that is created on the stack is.
[/quote]

Sorry for nitpicking here :-)

The pointer actually is destroyed (it is treated like an ordinary variable and it is created on the stack too), it's the object it points to that survives (and that is created on the heap). If you do not save the objects address somewhere else (explicitly or implicitly using e.g. Qt's parent-child-relationship of QObject based classes), that object is lost and can never be accessed again, thus leading to a memory leak.

loladiro

[quote author="Volker" date="1313088183"]
[quote author="loladiro" date="1313076273"]A pointer is not destroyed at the end of a function. A variable that is created on the stack is.
[/quote]

Sorry for nitpicking here :-)

The pointer actually is destroyed (it is treated like an ordinary variable and it is created on the stack too), it's the object it points to that survives (and that is created on the heap). If you do not save the objects address somewhere else (explicitly or implicitly using e.g. Qt's parent-child-relationship of QObject based classes), that object is lost and can never be accessed again, thus leading to a memory leak.[/quote]

Volker, you're right of course, should have mentioned that. Also, I don't mind nitpicking at all. It is quite useful to get the details right.