Why is it wrong to write this in a header file?

[canid]

hello,Why is it wrong to write this in a header file?

QSettings config("HKEY_LOCAL_MACHINE\\SOFTWARE\\mysoft", QSettings::NativeFormat);

[Chris Kawa]

The biggest two reasons:

• It violates one definition rule i.e. if you include this in multiple files you get multiple instances of the same object and it won't link.

• QSettings inherits QObject, which means it can't outlive QApplication object, which is usually created in main() scope. In short - don't create global or static QObjects.

[mrjj]

Hi
Just as a note.
You can have in .h if inside a class.

class MainWindow : public QMainWindow
{
    Q_OBJECT

    QSettings config{"HKEY_LOCAL_MACHINE\\SOFTWARE\\mysoft", QSettings::NativeFormat};
.......

note the { }

[canid]

@Chris-Kawa @mrjj
thank you
It would be nice if QSettings had a function that defined the construct parameters in the CPP file so that no memory was allocated repeatedly

[mrjj]

@canid
Hi
You mean the "Set" version of
https://doc.qt.io/qt-5/qsettings.html#fileName

?

[canid]

@mrjj
Yes, I think it should have this function: QSettings::setParameters(const QString & Filename, QSettings::Format Format)

[mrjj]

@canid
Ok. I understand.
Not sure there is a workaround. seems not.

I used it mostly via a class so didn't notice but I can relate to your use case.

That said. They made QSettings cheap to create so it might not be a huge loss.

[Chris Kawa]

It doesn't seem to be intended to be used like that, so you're kinda bending a square to look like a circle and complaining it still has sharp corners after that.
Keep in mind that QSettings does periodic syncing, so keeping it open for long time (entire app lifetime in your case) is not a good idea if you don't use it often. Unless you're working with some huge data set it's easier to just create an instance when you actually need it and keep it only for the short time you use it.

[JonB]

@canid said in Why is it wrong to write this in a header file?:

It would be nice if QSettings had a function that defined the construct parameters in the CPP file so that no memory was allocated repeatedly

The rest of you seem to understand, I don't, what memory is being allocated repeatedly?

[SimonSchroeder]

@canid said in Why is it wrong to write this in a header file?:

QSettings config("HKEY_LOCAL_MACHINE\SOFTWARE\mysoft", QSettings::NativeFormat);

I would understand that you don't want to type in this long line every time you are using QSettings. However, most of the time there is no reason to change the default places to store your settings. Nevertheless, you need to configure it properly to use storage for your own application only. The way you do that is that you set organization name and application name in QCoreApplication. Everytime you call the constructor of QSettings it will use these to configure the path to your storage.

It would be nice if QSettings had a function that defined the construct parameters in the CPP file so that no memory was allocated repeatedly

I have to agree with @JonB on this that I don't understand your concerns. Memory allocation is somehow expensive when allocating on the heap. There is no valid reason to do that for QSettings. Allocation on the stack, however, does not take any time at all. You loose marginally little time to initialize QSettings. But actually setting or reading a value using QSettings is an I/O operation which takes a lot longer than that. One major point here: Don't prematurely optimize!

My advice is this:

void foo()
{
    QSettings config; // use QCoreApplication::setOrganizationName/setApplicationName to configure in main()
    ...
}

This will be plenty fast.

[J.Hilk]

@SimonSchroeder said in Why is it wrong to write this in a header file?:

However, most of the time there is no reason to change the default places to store your settings

That's just presumptuous. I personally never use the default settings.

However, most of the time there is no reason to change the default places to store your settings

For once, it prevents proper polymorphism.

The way you do that is that you set organization name and application name in QCoreApplication. Everytime you call the constructor of QSettings it will use these to configure the path to your storage.

doesn't help you if you want any format but the NativeFormat, I use IniFormat to have consistency across all platforms.

I agree with @canid one should be able to set the filename and format somewhere else but the constructor

@Chris-Kawa said

QSettings does periodic syncing

yes, which is the only reason its derived from QObject, to hook into the QEvent System to flush on repaint requests

In my opinion, this has more drawbacks then benefits. Especially as the user is encouraged to create and destroy QSettings objects on the fly and therefore they never receive the update request

[SGaist]

@J-Hilk isn't QSettings::setPath what you are looking for to change the path outside the constructor ?

[J.Hilk]

@SGaist it helps sure, but

Warning: This function doesn't affect existing QSettings objects.

it only effects Qsettings instances, that are not yet created, so not really 😔

[SGaist]

@J-Hilk indeed, I was thinking about it at initialisation stage of your application.

[J.Hilk]

@SGaist mmh 🤔 right,

May be a better approach, than what I currently have. I'll have to test it. Thanks!