The difference between Qwidget object and pointer
-
I don't think the issue is with how you instantiate the QWidget. The way Qt works when one object is deleted all its children get deleted. The difference here is just when the QWidget will get deleted - when you use the "new" the object will only get deleted when the application exits and the OS reclaims the memory.
My guess it that you will get the same error using the pointer if you add after line 20 a
@
delete window;
@Most likely the issue is with Qt trying to delete the "textedit" or "layout" objects when the QWidget gets deleted.
Please note that is not good practice to leave for the OS to reclaim memory even if it seems to work.
The following code should work:
@
QApplication app(argv, args);
QTextEdit *textEdit = new QTextEdit();
QVBoxLayout *layout = new QVBoxLayout();
layout->addWidget(textEdit);QWidget window; window->setLayout(layout); window->show(); return app.exec();
@
replacing with (starting on line 6):
@
QWidget *window=new QWidget;
window->setLayout(layout);
window->show();int ret = app.exec(); delete window; return ret;
@
should also work.
-
This is a paragraph from the "C++ GUI Programming with Qt 4 - 1st edition by Jasmin Blanchette and Mark Summerfield (page 28):
bq. Qt’s parent–child mechanism is implemented in QObject. When we create an object (a widget, validator, or any other kind) with a parent, the parent adds the object to the list of its children. When the parent is deleted, it walks through its list of children and deletes each child. The children themselves then delete all of their children, and so on recursively until none remain.
This is a very good book and the first edition is available as a pdf for free. Look into the "Qt books" wiki.
-
[quote author="jandin" date="1294109520"]Thanks for your response. If I just follow the Qt doc "Getting Started Programming with Qt",I think I would get mad. :-)[/quote]
Have a look at the book I mentioned before. I usually can't stand programing books but I found this one very well written and easy to follow. Too bad I didn't know about it when I started with Qt :(
-
[quote author="jandin" date="1294104645"]@#include <QtGui>
#include "mainwindow.h"int main(int argv, char **args)
{
QApplication app(argv, args);
QTextEdit textEdit;
QVBoxLayout layout;
layout.addWidget(&textEdit);// 1.If I use the object,I will get an error whe I quit the application.
// Debug it,I get a signal SIGSEGV which means Segmentation fault
QWidget window;
window.setLayout(&layout);
window.show();
// 2.But if I use the poniter ,it is ok.
// QWidget *window=new QWidget;
// window->setLayout(&layout);
// window->show();
return app.exec();
}
[/quote]You really need to learn C++ and figure out why the two ways of doing things are different.
First of all, as people already said, you're implicitly using QObject parent/children mechanism, which means that destroying an object will automatically destroy all of its children.
Second, what's going on here is mandated by the C++ standard: automatic object destruction happens in the reverse order than automatic object construction, that is, the last object created is the one that is destroyed first.
What's the last object that was built? The "QWidget window". And its dtor wipes out (with operator delete) all its children, namely the layout and the textedit, which were allocated on the stack. Uh oh... operator delete on an object on the stack. That's WRONG!
What happens then? The dtors of the layout and of the textedit objects are run (WRONG! and WRONG! again, or, WRONG²!). Well, it's too late. Your program's memory layout is already FUBAR, and you've probably already got a weird crash by now.
If you use the @QWidget *window = new QWidget@ approach instead your application will leak memory (WRONG!) and tools like valgrind will complain and report: you never free the memory allocated there.
Of course, adding a @delete window@ (GOOD!) line after app.exec() will crash your application for the same reason stated above (WRONG!).
So, what you can do about that? Either
- allocate everything on the heap with operator new, then delete ONLY the widget with operator delete;
- allocate everything on the stack, but ensure that automatic object deletion doesn't interfere with QObject parent/children management, f.i.
@
QWidget w;
QLayout l;
QTextEdit te;
w.setLayout(&l);
l.addWidget(&te);
w.show();
@
will do the right thing (but think about why it will).
-
[quote author="peppe" date="1294111399"]
[quote author="jandin" date="1294104645"]@#include <QtGui>
#include "mainwindow.h"int main(int argv, char **args)
{
QApplication app(argv, args);
QTextEdit textEdit;
QVBoxLayout layout;
layout.addWidget(&textEdit);// 1.If I use the object,I will get an error whe I quit the application.
// Debug it,I get a signal SIGSEGV which means Segmentation fault
QWidget window;
window.setLayout(&layout);
window.show();
// 2.But if I use the poniter ,it is ok.
// QWidget *window=new QWidget;
// window->setLayout(&layout);
// window->show();
return app.exec();
}
[/quote]You really need to learn C++ and figure out why the two ways of doing things are different.
First of all, as people already said, you're implicitly using QObject parent/children mechanism, which means that destroying an object will automatically destroy all of its children.
Second, what's going on here is mandated by the C++ standard: automatic object destruction happens in the reverse order than automatic object construction, that is, the last object created is the one that is destroyed first.
What's the last object that was built? The "QWidget window". And its dtor wipes out (with operator delete) all its children, namely the layout and the textedit, which were allocated on the stack. Uh oh... operator delete on an object on the stack. That's WRONG!
What happens then? The dtors of the layout and of the textedit objects are run (WRONG! and WRONG! again, or, WRONG²!). Well, it's too late. Your program's memory layout is already FUBAR, and you've probably already got a weird crash by now.
If you use the @QWidget *window = new QWidget@ approach instead your application will leak memory (WRONG!) and tools like valgrind will complain and report: you never free the memory allocated there.
Of course, adding a @delete window@ (GOOD!) line after app.exec() will crash your application for the same reason stated above (WRONG!).
So, what you can do about that? Either
- allocate everything on the heap with operator new, then delete ONLY the widget with operator delete;
- allocate everything on the stack, but ensure that automatic object deletion doesn't interfere with QObject parent/children management, f.i.
@
QWidget w;
QLayout l;
QTextEdit te;
w.setLayout(&l);
l.addWidget(&te);
w.show();
@
will do the right thing (but think about why it will).[/quote]
thanks peppe,I can understand it totally now.
allocate everything on the heap with operator new, then delete ONLY the widget with operator delete;
allocate everything on the stack, but ensure that automatic object deletion doesn’t interfere with QObject parent/children management
So the example in the "Getting Started Programming with Qt":http://doc.qt.nokia.com/4.7/gettingstartedqt.html is wrong. It should be corrected.
-
Hi,
it goes a but farer. You should give the textedit a parent, as the text edit is not automatically reparented. So it should look like this:
@
QApplication app(argv, args);QWidget window; QVBoxLayout *layout = new QVBoxLayout(); window.setLayout(layout); QTextEdit *textEdit = new QTextEdit(&window); layout->addWidget(textEdit); window.show(); return app.exec();
@
The top level widget can be created on the stack, so it is then deleted automatically, or you can create it on the heap and use a smart pointer (scoped ptr) to automatically delete it. But child widgets MUST be created on the heap.
-
-
[quote author="jandin" date="1294109520"]Thanks for your response. If I just follow the Qt doc "Getting Started Programming with Qt",I think I would get mad. :-)[/quote]
Unfortunately the sample code in the Getting Started Guide is wrong and causes the application to crash. See the thread "Getting started example is buggy":http://developer.qt.nokia.com/forums/viewthread/2253/, it has a working version of the sample.
-
[quote author="Gerolf" date="1294128379"]Hi,
it goes a but farer. You should give the textedit a parent, as the text edit is not automatically reparented. So it should look like this:[/quote]
Actually not; putting it into the layout will automatically reparent it.
-
[quote author="Volker" date="1294147102"][quote author="Gerolf" date="1294128379"]it goes a but farer. You should give the textedit a parent, as the text edit is not automatically reparented.[/quote]
It actually is reparented. That's why the sample program of the getting started guide crashes.[/quote]
But it's only reparented, if the layout already is set to a widget, so creating the layout, adding widgets and the setting the layout to it's parent does not work.
-
[quote author="Gerolf" date="1294155697"]
But it's only reparented, if the layout already is set to a widget, so creating the layout, adding widgets and the setting the layout to it's parent does not work.[/quote]Yes it does. And does the right thing.
@
#include <QtGui>int main(int argc, char **argv)
{
QApplication app(argc, argv);
QHBoxLayout *layout = new QHBoxLayout;
layout->addWidget(new QTextEdit);
QWidget w;
w.setLayout(layout);
w.show();
return app.exec();
}
@ -
[quote author="peppe" date="1294156553"]Yes it does. And does the right thing.[/quote]
Correct. It is a two step process:
- layout takes ownership of the text edit on addWidget()
- widget w takes ownership of the layout on setLayout() and thus on all of the layout's widgets
-
[quote]layout takes ownership of the text edit on addWidget()[/quote]
No :-)
A QLayout cannot own a text edit. Remember: widgets can have only another widget as parent. Not arbitrary QObjects.
What happens is that the QLayout simply "remembers" about the text edit; the reparenting happens when setLayout() is called. After that, the hierarchy will be something like
- QWidget
** QLayout
** QTextEdit
(notice that the layout and the text edit are siblings and both children of the QWidget).
- QWidget
-
Peppe, your right. I mixed up things from what I looked up in the sources some times ago. The layout only keeps book of the widgets it manages, but does not take ownership.
But what's really important for the users: After the UI is set up, all parent-child relationships are correct. I really do like Qt :-)