Global functions?

jsulm

@KillerSmath Singleton should be avoided for many reasons. For QSettings there is no need for a singleton as creating QSettings instance after configuring is cheap.

KillerSmath

@jsulm said in Global functions?:

@KillerSmath Singleton should be avoided for many reasons. For QSettings there is no need for a singleton as creating QSettings instance after configuring is cheap.

Yes, yes, it was my mistake, i forgot the Qsettings unique file save model

kshegunov

@KillerSmath said in Global functions?:

@GCDX
What do you think about Singleton design pattern ?

http://lengthily.blogspot.com/2017/02/one-size-fits-all.html

KillerSmath

@kshegunov
Thank you for the support material. Everyday i'm learning something new and improving some of my concepts about the programming world :)

JonB

@jsulm

as there is no need for a "global" QSettings:
For QSettings there is no need for a singleton as creating QSettings instance after configuring is cheap.

I presently do create a single "global" object for my QSettings to guarantee "efficiency". I have questions about changing over to creating new instances when needed.

I am happy to call QCoreApplication::setOrganizationName/setOrganizationDomain/setApplicationName() once.

I use QSettings::IniFormat unconditionally on both Windows & Linux. I may wish to specify the filename/path (undecided).

Constructing a QSettings object (for reading settings, dotted all over my code) is only "cheap" provided somewhere Qt has cached the (parsed) content once and knows when to re-use that for all sundry QSettings settings statements. Otherwise it's "expensive" (IMO).

What exactly do I need to do/call to keep being able to construct new QSettings objects "cheaply"? I don't see where docs explain what exactly will be cached. For example:

Is every call to constructor QSettings::QSettings(const QString &fileName, QSettings::Format format, QObject *parent = nullptr) guaranteed to fetch a cached object for every unique combination of fileName & format?
Does calling QSettings::setDefaultFormat(QSettings::Format format) instead of specifying it in constructor give me caching for that?
Similarly, does calling QSettings::setPath(QSettings::Format format, QSettings::Scope scope, const QString &path) instead of each time in constructor give me a caching for the combination?
Finally, I note that if I need QSettings::setIniCodec() that is an instance function and not static. I would have to call that on each created instance, and the implication (to me) is that it would require the file to be re-read each time.

If by any chance QSettings is not doing any of this caching then I think the suggestion that QSettings settings; is "cheap" is very misleading....

jsulm

@JonB Well, I don't know whether QSettings caches anything. The question is: how often do you read/write settings? If this is something you do often in your app I would consider writing a wrapper class which reads the settings once and writes changed values only if you ask it to do so. This way you have more control, but you would need to make sure you use same instance everywhere.

JonB

@jsulm
Reading settings is/may be dotted randomly all over the code (not my code, previous authors felt they could read a setting whenever it suited them, all sorts of stuff is saved in settings file).

I agree totally then about "make sure you use same instance everywhere", but that indeed takes us back to the opposite recommendation given to the OP! Even if it's wrapped in a convenience class, that class needs a global instance or singleton.

Which is where the OP started from! Unless QSettings promises some kind of caching (at least for my choice of QSettings::IniFormat), I don't mean to sound rude but suggesting that you can get away without global/singleton and just create instances is "misleading" or "requires a qualified explanation" IMHO. [If you only access the settings once in code, you may as well not bother with the static initialization functions like QCoreApplication::setOrganizationName and you won't go QSettings settings more than once anyway.]

jsulm

@JonB In my opinion it really depends on the app. Even if you read/write settings at many places - is it really performance relevant? Do you read/write settings in a long lasting loop? How often do you read/write settings? Why do you think it is important to have some caching in QSettings? Don't forget it would increase RAM consumption - for what? Don't over-engineer.

kshegunov

QSettings will create global objects internally (thus the documentation). So when the program is ending the cleanup routines will call sync() and will flush the changes. Also you can call sync() manually to flush the changes. If I recall correctly, the settings object will cache the read data and they will also monitor the settings file for changes (due to other settings objects of other application(s) writing something) and update the cached information.

I actually don't like how the settings work in principle, I'd very much have liked this to be left to the user code.

This should give an answer to your other concerns.

JonB

@jsulm
We'll agree to differ then :) Do I (rather the code) read settings in a loop? Who knows? No reason why it shouldn't. Especially when I'm just told "creating a new QSettings object is cheap", but nothing is said about the cost of then going QSettings::value() which is what I'm going to want to do. IMHO anything which might involve repeatedly opening a file, reading it and then parsing it is hugely expensive time-wise (RAM-wise, one common INI file content is not big).... Anyway, for me if not necessarily the OP, the moral is I do want a single, permanent object.