[qt] Несколько объектов QSettings В одной программе.

If you use QSettings from many places in your application, you might want to specify the organization name and the application name using QCoreApplication.setOrganizationName() and QCoreApplication.setApplicationName(), and then use the default QSettings constructor:

QCoreApplication.setOrganizationName(«MySoft»);
QCoreApplication.setOrganizationDomain(«mysoft.com»);
QCoreApplication.setApplicationName(«Star Runner»);
...
QSettings settings;

Ээээ если ты создаешь его как QSettings *settings = new QSettings() тогда ты ССЗБ. А по уму он сам удалится после того, как ты сохранишь/загрузишь что нужно

> Ээээ если ты создаешь его как QSettings *settings = new QSettings() тогда ты ССЗБ.

оно же persistent, так нельзя несколько раз.

Ну и тем более. Впрочем QSettings не самая сильная сторона Qt, есть у него одна бага веселая.

Хм, я не знаю, у меня обычно в каждый класс, который читает настройки, запихан QSettings. Но он вроде как один вообще внутри QApplication.

Что вы какой-то чуши пацану насоветовали? QSettings это обычный класс, не более того. Его можно создавать сколько угодно раз. QCoreApplication.setOrganizationName(«MySoft») и тому подобное делается для того, чтобы для всего приложения задать дефолтное расположение настроек. Ты можешь хоть каждый раз создавать этот объект с новыми параметрами. Так что используй сколько угодно этих объектов - все будет нормально работать.

Что еще за бага? Подробности в студию!

> The QSettings class provides persistent platform-independent application settings.
...

If all you need is a non-persistent memory-based structure, consider using QMap<QString, QVariant> instead.

см. doc.trolltech.com/4.3/qsettings.html в секции «Fallback Mechanism» есть пример. ТСу, я так понимаю, именно это и нужно.

Но а что скажешь по этому поводу?
QSettings::QSettings ( const QString & fileName, Format format, QObject * parent = 0 )
Используется нормально на разные ини файлы. В один момент.

ну и в чем проблема? на оффсайте, как я понял, не рекомендуют _создавать_ несколько объектов QSettings.

Да, если они нацелены на 1 файл.

Creating multiple, simultaneous instances of QSettings writing to a text file may lead to data loss!

Из цитаты не очевидно что если файлы разные то все будет ОК.

Угу, не очевидно, да и к версии 4.5 уже это фикс. Но если читать доку, то это подразумевается, а если посмотреть в сорс, то это очевидно. Не знаю, возможно я и не прав. Но использование нескольких сеттингов на разные конфиги меня еще не подводило.

>ну и в чем проблема? на оффсайте, как я понял, не рекомендуют _создавать_ несколько объектов QSettings.


Вот я так и считал, как говорит мужик. Но потом задумался о том, что это не рекомендуется.

>>Вот я так и считал, как говорит мужик. Но потом задумался о том, что это не рекомендуется.

Если ты только читаешь с этих объектов - то все в порядке, никаких потеря данных не будет, потому что работа после создания объекта идет в памяти. Как говорится, до первого sync(). Если же ты одновременно читаешь и пишешь - да, могут возникнуть сложности, как и с любым файлом.

При выполнении конструктора данные будут считываться. При выполнении деструктора или по другим условиям конфиг будет записываться.

Да, тогда могут случиться неприятные вещи. Либо используй только один объект, либо разноси настройки по разным файлам.

нацеленные на разные конфиги - без проблем. Если нацеленные на один конфиг, и подразумевается что данные будут и читаться и записываться, то можно поиметь проблемы синхронизации. Я такое уже видел, только в один конфиг писали два разных процесса.

но в доках английским языком написано:

If a setting is modified through one QSettings object, the change will immediately be visible in any other QSettings objects that operate on the same location and that live in the same process.
QSettings can safely be used from different processes (which can be different instances of your application running at the same time or different applications altogether) to read and write to the same system locations. It uses advisory file locking and a smart merging algorithm to ensure data integrity. Changes performed by another process aren't visible in the current process until sync() is called.

я не помню всех ньюансов, но то что проблемы были это точно. Если найду тесткейс - покажу.

Да, тогда могут случиться неприятные вещи. Либо используй только один объект, либо разноси настройки по разным файлам.

Т.е. что-то в духе

QSettings set1, set2;
set1.setPath( config1 );
set2.setPath( config2 );

?

Да, что-то в таком духе. Если будешь писать в обычные инишки - то проблем не будет. Читать и писать в файл одновременно в принципе дурной тон.

>Да, что-то в таком духе. Если будешь писать в обычные инишки - то проблем не будет. Читать и писать в файл одновременно в принципе дурной тон.


Понятно, спасибо за пояснение. Осталось покурить маны и браться за дело.