[solved] stack / heap object question
-
Is there a way to use an on stack created Object in event routine of the same class ?
... or is the only way to do this an on heap created object by using "new" ?mainwindow.h
@private:Ui::MainWindow *ui; QSettings settings_stack; QSettings *settings_heap;@mainwindow.cpp
@#include "mainwindow.h"
#include "ui_mainwindow.h"MainWindow::MainWindow(QWidget *parent) :
QMainWindow(parent),
ui(new Ui::MainWindow)
{
ui->setupUi(this);QSettings settings_stack("MySoft", "Star Runner"); settings_stack.setValue("editor/wrapMargin", 42); qDebug() << settings_stack.organizationName(); qDebug() << settings_stack.applicationName(); qDebug() << settings_stack.value("editor/wrapMargin").toInt();}
MainWindow::~MainWindow()
{
delete ui;
}void MainWindow::on_pb_1_clicked()
{
qDebug() << settings_stack.organizationName();
qDebug() << settings_stack.applicationName();
qDebug() << settings_stack.value("editor/wrapMargin").toInt();
}
@thank you
-
In line 10, you are creating a local variable named settings_stack. It will be destroyed once the constructor ends (line 16). So what you access in line 25 is a completely different object.
There are several ways to make it work, I highly recommend reading some book on C++ to get the general idea. The shortest solution right now (others would require a bit of rewriting) is this:
@
// Replace line 10 of your code with this:
settings_stack = QSettings("MySoft", "Star Runner");
@
-
I tried this first, but:
build error >> operator '=' is private
-
Ah sure, it inherits from QObject, I forgot. OK, then you need a partial rewrite to use the heap-allocated version.
This means that you need to change:
@
settings_stack. into settings_heap->
@Because those will be pointers now. And the now-famous line 10 becomes:
@
settings_heap = new QSettings("MySoft", "Star Runner");
@
-
using the heap way is quite clear.
I wanted to know if there is a possibility to manage this problem
without "new".
I guess : It's not possible, right ?
-
There is: create on stack every time you read or save your settings (so, no member variable in your class, only local variables). QSettings is quite fast, so you don't need to worry about performance (plus, settings are usually not being read or saved all that much, are they?).
-
This is just an example for learning stack/ heap usage.
If i really need it, i would prefer the heap approach, anyway.Thank You
-
Right, then please remember that for "normal" C++ classes (QString, QByteArray, QPoint, etc.) the first approach with stack would work (see my initial answer). It does not work in the special case of QSettings, because all QObjects (including QWidgets) are non-copyable (they cannot be copied). This is because copying QObject would break the parent-child hierarchy (don't ask me how, though. Somebody made a decision about that years ago and it has stayed this way ever since).
-
Your recent post makes things clear now.
thanks again !
-
Hi,
QSettings being a special case and to simplify a bit things, you should follow the example of the documentation that is a bit further:
@
QCoreApplication::setOrganizationName("MySoft");
QCoreApplication::setOrganizationDomain("mysoft.com");
QCoreApplication::setApplicationName("Star Runner");QSettings settings;
@It it'l make you code more readable and QSettings even easier to manage.
-
Ok, also interesting:
I set some values for in line 1, 2 and 3 for the actual application
and then create QSettings object in line 5 which already contains
the values for OrganizationName and ApplicationName, readable using QSettings::organizationName() and QSettings::applicationName() properties.Whats about line 2 'OrganizationDomain' ?
Seems there is no property organizationDomain() in QSettings.
Is the domain also stored in Qsettings or what demonstrates line 2 in the context of QSettings ?
-
Please read the documentation for "QSettings":http://qt-project.org/doc/qt-5/QSettings.html Organization name is needed on Mac to properly save your settings (that is, to save them in a meaningful path/ filename).
-
bq. (Here, we also specify the organization's Internet domain. When the Internet domain is set, it is used on Mac OS X instead of the organization name, since Mac OS X applications conventionally use Internet domains to identify themselves. If no domain is set, a fake domain is derived from the organization name. See the Platform-Specific Notes below for details.)
So this part is only interesting for Mac users, right ?
-
Yes, but it is good practice to always use it. This way future porting is easier plus you can get support for new platforms for free, without refactoring.
-
ok, clear now, thx !
