When to call destructor..?
-
Here is what my class looks like
@class Window : public QWidget
{
Q_OBJECT
public:
Window();
static bool fullscreen;
protected:
void keyPressEvent(QKeyEvent *event);
private:
GLWidget *glWidget;
};
@and I am calling allocating memory in constructor by calling
@glWidget = new GLWidget;
QBoxLayout *mainLayout = new QBoxLayout((QBoxLayout::Direction)0, 0);@now, when do I call destructor to call delete glWidget and mainLayout..?
I mean how exactly will I know when window is closed?I read something like "reimplementing" closewindow event; but I do not wish to "reimplement" it, all I want is to clear the durt I have created and then pass on the control to qt; I do not want(rather cannot) to clear the durt created by Qt internally.
Thanks
Andrew -
You don't call destructors, they are called when the objects are deleted.
If you simply want to have your glWidget destroyed, there are several possibilities:
-
Have your glWidget be a child of Window <- Automagically done for your when Window is destroyed
-
Have your glWidget in a layout set on Window <- Automagically done for your when Window is destroyed
-
Delete it in the destructor of Window.
I would also suggest to have a look at Qt's documentation about widgets and parent/child relationtionship.
Hope this helps
-
-
Thanks SGaist for the reply
Well, actually I believe we can certainly call destructor. And it should be called if needed.. there is nothing wrong in it. In my particular case I do not want to delete memory allocated in contructor but want to free contents of GLWidget, so I want to call destructor and use the memory in my own way..
So I would like to know how to handle close window event..?(of course without reimplementing it entirely..)
Thanks
Andrew -
Explicitely calling a destructor is not incorrect, it just looks plain wrong and I would discourage anyone from doing it. If you need to cleanup some resources create a member cleanup() or reset() or anything, put that in the destructor and call that instead.
Something like this in someones code would scare me a bit and make me question his code for sure:
@
void MyClass::someMember() {
this->~MyClass();
doSomething(this->someMemebrPtr);
}
@Now on to the actual topic.
There is no signal windowClose, but there is closeEvent. You don't have to reimplement it entirely, just call the original implementation inside:
@
void Window::closeEvent(QCloseEvent *event)
{
//do stuff...
QWidget::closeEvent(event);
}
@
Other thing is you could install an event filter like installEventFilter(this) and then in the re-implemented eventFilter() check for QCloseEvent. This however has little sense since you re-implement some events anyway it might just be closeEvent. -
Hi there,
Think that calling a delete is never a "bad" thing and it shows good programming insight that you should clear up your own mess.
For Qt however when using the QObject options wisely you are able to dismiss the use of the delete at all. When you set Window as the child of someone else (give the parent pointer to the contructor) the closing of the Window class will automatic destroy any memory allocated in that class. It will even take into account references and pointer to allocated memory that are given to other classes. It won't destroy it until no one needs it anymore. Qt is very good in that. A bit the same as a garbage collector in Java etc.
The destructor is called when your class isn't referenced any more and memory may be released to the system. This is done after the closeEvent. So don't confuse them!
Greetz -
[quote author="Jeroentje@home" date="1361376161"]
Think that calling a delete is never a "bad" thing and it shows good programming insight that you should clear up your own mess.[/quote]
Calling delete operator - absolutely, bu we were talking about calling destructor without the delete operator.
[quote author="Jeroentje@home" date="1361376161"]
For Qt however when using the QObject options wisely you are able to dismiss the use of the delete at all. [/quote]
I second that. You should also use techniques like RAII in your own classes. The goal is to have to call delete as little as possible.
[quote author="Jeroentje@home" date="1361376161"]
A bit the same as a garbage collector in Java etc. [/quote]
This is not true and please don't tell that to people or we will have endless questions about performance of Qt etc. Qt, as C++ itself has a very strict and deterministic object destruction order and policies unlike garbage collection which adds overhead of reference counting, objects address tracking, can occur at any moment or not at all and take undetermined amout of time.
[quote author="Jeroentje@home" date="1361376161"]
The destructor is called when your class isn't referenced any more and memory may be released to the system. This is done after the closeEvent. So don't confuse them!
Greetz
[/quote]
This is simply not true. There is no reference counting involved (unless you use something like QSharedPointer). This is simple parent-child relation. Parent is responsible for destroying children. There are subtleties when it comes to threading and event delivery but basically that's it. The only other way a widget can be destroyed automatically is if it is the last closed window (QApplication takes care of that) or if you set WA_DeleteOnClose attribute on it. -
Basic Qt classes use the flyweight reference counting IYAM, so yes, some do use reference counting.
Your very correct that a garbage collector absolutely isn't the same as proper memory management in Qt or C++!! It was more a bit of information what it looks like, not that it works the same way or uses the same resources etc. IYAM garbage collectors are bad and for lazy not thinking properly programmers. Letting the system determine what memory to be released etc, terrible. Learn proper coding and do it your self! That's my motto.
So, to end this forum, the destructor will be called automatic and shouldn't be called explicit. Calling delete (what original was intended here) may be skipped by the good memory management in parent/child behavior in Qt. -
[quote author="Jeroentje@home" date="1361434776"]Basic Qt classes use the flyweight reference counting IYAM, so yes, some do use reference counting.[/quote]
They do use copy on write(so called implicit sharing) but that's not ref counting. Can you give an example of such a class? I couldn't find any myself after a brief search.
-
IIRC implicitly shared containers in Qt indeed use reference counting.
-
Ah, right, that actually makes sense if I think about it.
But still - it doesn't mean that dynamically allocated QSting* will be deleted automatically. It just means that the internal character array will be deleted when no QString is left using it.
-
I certainly wouldn't. I'm just making a point :) Yep. I guess we're all agreeing here now.
