The difference between Qwidget object and pointer
-
[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 :-)