Avoid dangling QTimer object
-
Hi,
Why do you need to delete your timer ?
From the looks of it, handling it with start and stop seems like it would be enough. -
Hi,
Why do you need to delete your timer ?
From the looks of it, handling it with start and stop seems like it would be enough.@SGaist said in Avoid dangling QTimer object:
From the looks of it, handling it with start and stop seems like it would be enough.
Because I know that the MainWindow deletes it as it is its parent but I always avoid doing so when the object can be created dynamically multiple times and that what happens in my app, the timer can be created with new dynamically as long as the app stays open, thus , even if it is small, it will be consuming memory.
-
@hbatalha said in Avoid dangling QTimer object:
connect(timer, &QTimer::timeout, this, &MainWindow::taskUpdate);
You can connect a lambda to the slot and pass the timer as parameter to lambda and then to the actual slot:
connect(timer, &QTimer::timeout, [this, timer]() { MainWindow::taskUpdate(timer)});
@jsulm said in Avoid dangling QTimer object:
connect(timer, &QTimer::timeout, this, timer { MainWindow::taskUpdate(timer)});
Nice suggestion, I had thought about lambda but it was in a different way.
Thank you, I will probably change my code to this. -
@SGaist said in Avoid dangling QTimer object:
From the looks of it, handling it with start and stop seems like it would be enough.
Because I know that the MainWindow deletes it as it is its parent but I always avoid doing so when the object can be created dynamically multiple times and that what happens in my app, the timer can be created with new dynamically as long as the app stays open, thus , even if it is small, it will be consuming memory.
@hbatalha said in Avoid dangling QTimer object:
the timer can be created with new dynamically as long as the app stays open, thus , even if it is small, it will be consuming memory.
Do you really think the downsides (make sure to delete it every time you don't need it, continuous memory (de)allocation) is it worth for ~20bytes? A member which is allocated one time would be much easier here.
-
@hbatalha said in Avoid dangling QTimer object:
the timer can be created with new dynamically as long as the app stays open, thus , even if it is small, it will be consuming memory.
Do you really think the downsides (make sure to delete it every time you don't need it, continuous memory (de)allocation) is it worth for ~20bytes? A member which is allocated one time would be much easier here.
Sorry for the late reply!
@Christian-Ehrlicher said in Avoid dangling QTimer object:
Do you really think the downsides (make sure to delete it every time you don't need it, continuous memory (de)allocation) is it worth for ~20bytes?
Actually that never crossed my mind, thanks. Are there any best practices guide for memory management in Qt?
A member which is allocated one time would be much easier here.
Does the same apply for Dialogs? Just an example:
void MainWindow::onPushButtonClicked() { SomeDialog* diag = new SomeDialog(this); diag->setWindowFlags(Qt::WindowStaysOnTopHint); diag->setWindowFlags(Qt::Dialog); diag->exec(); m_name = add->lineEdit->text(); m_password = lineEdit2->text(); }
Should I just do it like this:
SomeDialog*diag.; ... diag.exec();
Since I don't need
SomeDialog
outside that block of code.Edit: I researched a little and found that since
.exec()
is blocking the object will not run out of scope so I should put them on stack. -
void MainWindow::foo()
{
...if(checkTaskCompletion == true) { // timer is declared in the mainwindow class if ( nullptr == timer ) { timer = new QTimer(this); connect(timer, &QTimer::timeout, this, &MainWindow::taskUpdate); } if ( !timer->isActive() ) { timer->start(2'000); } }
}
you can call foo n times.
-
void MainWindow::foo()
{
...if(checkTaskCompletion == true) { // timer is declared in the mainwindow class if ( nullptr == timer ) { timer = new QTimer(this); connect(timer, &QTimer::timeout, this, &MainWindow::taskUpdate); } if ( !timer->isActive() ) { timer->start(2'000); } }
}
you can call foo n times.
-
@JoeCFD , @ anyone
Why not have just oneQTimer timer
instance as a class member? Nonew
ing, nodelete
ing.See also https://forum.qt.io/topic/124404/class-pointer-and-non-pointer-member-function-question !
-
@JonB I assume s/he has only one. It may be a good practice to write code like that. No more worries about crash or multiple calls to foo.