Following up on this answer, I can declare the objects inside a Qt application as:
QLabel *label {new QLabel("bla")};
or
QLabel label {QLabel("bla")};
Let's assume that the app gets large enough; won't the stack risk getting too "crowded" with Qt objects (and the rest of the program) if I declare them as the 2nd way, even if it means it's faster? If so, how can I know when to avoid the 1st method over the 2nd?
You cannot get a definitive answer for "is it better to allocate on the heap or on the stack ?", which is the question you're asking.
Like said in the comments, large object should not be allocated on the stack but there is no clear limit and it would depend on many thing like the stack size or the hardware the program will be running on.
Also I'd like to note that if you can be sure that QLabel *label {new QLabel("bla")}; will be allocated on the heap (unless you reimplemented the new operator), you cannot say where QLabel label {QLabel("bla")} will be allocated.
Now you are talking about Qt. The way Qt and the QObject philosophy is designed, the syntax with pointers for QObject derived class would be preferred. But there are no rational argument against using the other form.
Also because Qt is using the d-pointer to hide its implementation details, QObject derived classes provided by Qt should not be extensively large.For instance even if you allocate a QLabel on the stack (24 bytes) most of its internals will be allocated on the heap (404 bytes).
The 2nd way you present won't work since QLabel is not copyable and thus the code won't compile. Perhaps you've meant
QLabel label{"bla"};
Furthermore, it has nothing to do with the stack at all. You could have written that line within a class:
class MyUi : public QWidget {
QGridLayout m_layout{this};
QLabel m_label{"bla"};
};
And, usually, you're supposed to do exactly that. You could of course allocate the widget as an automatic variable - usually this will only happen within main:
int main(int argc, char **argv) {
QApplication app{argc, argv};
...
MyUi ui;
ui.show();
return app.exec();
}
Here you need to use some common sense. How big will that class really get? Note that all Qt classes that derive from QObject use PIMPL and are either the size of a pointer, or the size of a couple of pointers - thus quite small.
In most cases, you shouldn't be worrying about it. If you run out of stack when your project gets truly huge, allocate MyUi dynamically and that's all:
int main(int argc, char **argv) {
QApplication app{argc, argv};
...
auto ui = std::make_unique<MyUi>();
ui->show();
return app.exec();
}
I've never ran into that problem personally: if your MyUi class is big enough, you've probably got serious issues with your design, and the class is way too monolithic and has too much responsibility.
