Один из методов работы с конфигурационными файлами в С++ (Qt)

[@EvilsInterrupt]

Задав в поиске на хабре «QSettings» и нашлось больше 5 тем не включая вашу. В чем новизна? Что есть у Вас чего нет в официальной документации?

[@unixod]

В чем новизна? Что есть у Вас чего нет в официальной документации?

Осмелюсь спросить: Вы читали пост целиком? :)

Задав в поиске на хабре «QSettings» и нашлось больше 5 тем не включая вашу.

Если Вы все же читали пост целиком (ну или хотябы чуть дальше середины), то могли бы заметить что все те статьи, что выдает поиск, никак не касаются вопросов затронутых здесь. Там применяется простой метод использования QSettigns. Здесь же я описываю, метод работы с конфигами и его реализацию, которая не привызанна именно к QSettings, я же написал в статье:

В данной реализации, класс QSettings, используется исключительно для кроссплатформенного доступа к настройкам. Конечно же по желанию QSettgins может быть заменен любым другим механизмом, например SQLite.

Наверное я неправильно начал введение, что у читателей сводится мнение что все дальнейшее будет касаться исключительно работы с QSettigns.

[@EvilsInterrupt]

То что Вы осветили это материал тянет на «капитанский» уровень. В вашем материале нет ничего того, чтобы Вас выгодно позиционировало. Все обыденно. На мой взгляд Вам нужно копнуть глубже в свою голову и поделиться тем, что реально экономит людям время и не на 1-2 дня, а на неделю!
У Вас же выглядит все так: Чел столкнулся с проблемой — чел почитал документацию — чел подумал — чел написал код. Все что Вы написали это максимум 3 человеко\дня работы и это еще очень завышенная оценка.

Примеры задач, которые, на мой взгляд, имеет смысл рассматривать:
1) С++ программеры, да и не только, часто пишут абстрактные классы для задания интерфейса, а потом сталкиваются с задачей чтобы от него написать потомка. Можно было бы написать скрипт, который парсит хидер с таким базовым классом и создает *.cpp/*.hpp файлы с готовым к наполнению потомком. Это бы многое упростило другим.
2) Часто админы, не важно фрихи или линухов, правят конфиги и часто выливается это в экспериментирование, если есть неясный нюанс. Конечно на боевом сервере это не будут, но и на тестовом тоже нужно затратить время. Можно было бы написать нечто что смотрит на настройки и текущую систему и пишет хинты админу где он накосячил и что можно поправить? Это бы тоже дало реальную пользу многим людям.

Писать имеет там, на мой взгляд, где люди экономят свое время или узнают такие нюансы, которые помогают решить им серьезные вещи, к примеру отладить их трудноуловимые баги.

Надеюсь ясно выразил мысль

[@Fedcomp]

А мне статья понравилась. Людям которые решают серьезные вещи и деньги платят серьезные чтобы они сами разбирались.

[@EvilsInterrupt]

Нет. Ошибочное мнение. Людям платят серьезные деньги по другим причинам. Все современные продукты разрабатываются минимум 3 разработчиками. Для любой команды всегда будет дешевле, когда участник столкнувшийся с проблемой пойдет и спросит других участников команды. Людям платят серьезные деньги за то что они умеют решать проблемы! Как правило до них никто эту проблему не решал или слишком много серьезных проблем, которые в гугле хоть и описаны, но нужен очень серьезный уровень знаний чтобы описанное понимать. Это как понимать решение уравнений вида «2 + x = 5» и совсем другой уровень вычисления в конечных полях.
То что описано в статье описано в документации! А чтение документации это одно из требований к любому программисту. Чтении документации это не обсуждаемый навык, это просто должно быть в крови у любого программиста!
Другое дело, когда человек сталкивается не тривиальной проблемой, которую не описали в документации или вдруг в библиотеке встречается баг\фича тогда согласен, имеет смысл описать ситуацию со всех сторон, т.к. это действительно поможет кому-то не наступить на грабли или быстрее решить проблему

[@IGHOR]

А еще с помощью QSettings можно читать\писать любые ветки реестра и записывать настройки в ini файл.
В документации Qt о QSettings все подробно написано.

От себя могу добавить что запись настроек в файл в случае падения системы (отключили электричество, BSOD..) не надежна.
И в после загрузки можно получить пустой файл и потерять настройки.
В таком случае советую дублировать файл и в случае чего заменять из бэкапа обратно.

[@fuCtor]

А еще можно установить свои функции чтения/записи и писать в БД или XML.

[@EuroElessar]

compile-time check

[@unixod]

Самое главное это, как написал выше EuroElessar:

compile-time check

Если же было принято решение вынести ключи, в виде строковых констант, например в отдельное пространство имен, можем столкнуться со следующим (вырезка из поста):

* во первых слишком многословно, т.е. информация дублируется (key1 -> «key1», и т.д.).
…

* во вторых при достаточном количестве ключей и секций, велика вероятность, что придется прописывать константы для всех комбинаций, что не очень удобно.
…

Тут стоит пояснить поподробнее. Если первый пункт («многословность») можно отнести чисто к взгляду с эстетической точки зрения, то второй пункт затрагивает некоторые практические моменты.

Например предположим что у нас в настройках надо хранить два пароля для FTP и для HTTP серверов:

в предлагаемом мною методе нам достаточно определить два enum's таким образом (дефолтную секцию General для наглядности опустил):

//Settings.h
class Settings{
    ...
public:
    enum Section{
        HTTP,
        FTP
    };

    enum Key{
        Password
    };

    ....

};

Альтернативный вариант c использованием констант:

//Settings.h
class Settings{
public:
    typedef const char * Section;
    typedef const char * Key;

    static Section HTTP;
    static Section FTP;
    static Key Password;

    ...

};

//Settings.cpp
Settings::Section Settings::HTTP = "HTTP";
Settings::Section Settings::FTP = "FTP";
Settings::Key Settings::Password = "Password";

А теперь представим что нам надо добавить еще 2 ключа — URI и Login (для HTTP и FTP серверов)

Вариант с «магическими» enums требует минимальных изменений — всего-лишь надо добавить два элемента в перечисление Key:

//Settings.h
class Settings{
    ...
public:
    enum Section{
        HTTP,
        FTP
    };

    enum Key{
        URI,
        Login,
        Password
    };

    ....

};

Вариант с классическими константами требует куда больше изменений:

//Settings.h
class Settings{
public:
    typedef const char * Section;
    typedef const char * Key;

    static Section HTTP;
    static Section FTP;
    static Key URI;
    static Key Login;
    static Key Password;

    ...

};

//Settings.cpp
Settings::Section Settings::HTTP = "HTTP";
Settings::Section Settings::FTP = "FTP";
Settings::Key Settings::Password = "URI";
Settings::Key Settings::Password = "Login";
Settings::Key Settings::Password = "Password";

Из приведенных выше примеров можно заметить, что вариант использующий классические константы требует больших изменений как в *.h так и в *.cpp файлах. Этого конечно же можно избежать если вынести константы в хеадер в отдельное пространство имен (как описано в посте), или же обозначить их как constexpr (но это уже требует поддержки C++11). Но в любом случае реализация получится более многословной => усложнение модификации.
Можно привести еще много фактов в пользу применения описанного тут метода по сравнения с применением констант, но это потребует куда большего объема текста чем этот комент)