QJson, а сверху сам помажешь как тебе надо.

На самом деле у тебя не так много вариантов хранения. ini, JSON, YAML, XML. По большому счёту это всё что есть, если не прибегать к чему-то малоизвестному, специфичному (csv для электронных таблиц) или базам данных.

В boost/poco есть для этих целей что-то. Еще (хотя это и не очень легковесно) удобно настройки хранить в MongoDB, т.к. легко добавлять всякие структуры с иерархией. А вообще не понятно, что значит

QSettings мне не понравился тем, что вывод в ini не очень читабелен

QSettings из коробки в .ini файлы настройки загружает. ТС-у лень свою обёртку писать/переделывать существующую и он ищет готовую. Всё как обычно в ковырянии кода на плюсах.

Я как-то не работал с json средствами Qt. Неужели у Qt нет в комплекте ничего для этого?

https://stackoverflow.com/questions/42060573/save-ui-settings-with-qsettings-...

Но там надо чуть вправо и влево ходить. У ТС-а скорее всего просто опыта не хватает чуть чуть и он теряется. Я пока не полез в более понятные языки, вроде шарпа тоже терялся, а потом мозги на место встали, когда почувствовал что можно код писать, а не только с синтаксисом крестов воевать. QJson и есть

QJson, а сверху сам помажешь как тебе надо.

уже так делал однажды - в итоге годно, но ну его, сейчас хочется готового решения

ini, JSON, YAML, XML

да, но сам по себе JSON и т.п. - это форматы, мне же нужен сериализатор/десериализатор в них из контенеров, таких как QVariantMap или любых других подобных

Ну QJson чем не угодил?

https://habr.com/ru/post/147952/

Читай, там и сериализация есть. Я уже 2 ссылки кинул. Тебе по сути только библиотека для работы с форматом и нужна.

Дело в том, что я уже написал обёртку на QSettings, но читабельность результата сериализации меня не до конца устраивает. Если же мне придётся писать толстую обёртку над чем-то другим, то проще забить.

Ну значит либо плохо написана обёртка и надо по-человечески просто написать (соблюдая KISS), либо у тебя совсем какая-то жирная муть и надо брать в руки базу данных для хранения.

Это на линуксе, в винде пишет в реестр, а на ябблопродукции в бинарные .plist файлы, если правильно помню

Зачем ты туда вообще смотришь, начнём с этого

Это как настроишь. Я давно уже не трогал QSettings и вообще кресты (год отдыха от больного языка, сижу в питоне и балдею), но вроде там конструктору можно скормить QSettings::IniFormat и будет везде ini.

да и именно так я и сделал

Самый человеко-читаемый формат - это json.

А теперь делай через QSettings::registerFormat

зачем?

Начиная с какой-то версии, ЕМНИП, кусеттингс умеют не только в ini

а на ябблопродукции в бинарные .plist файлы, если правильно помню

plist на маках это обычный XML

А что мешает указать QSettings, что тебе нужен не INI, а XML или что-то другое: https://doc.qt.io/qt-5/qsettings.html#registerFormat ?

Но не самый удобный, когда надо редактировать конфиг.

libconfig

Практически, как json, c++ интерфейс достаточно удобен

мне нужен не просто другой формат, а читабельная сериализация

Поищи на github’е QJsonSerializer - прекрасно работает

QtJsonSerializer, sorry

github.com

мне нужен не просто другой формат, а читабельная сериализация

Вот как сделано у нас: https://github.com/Stellarium/stellarium/blob/master/src/core/StelIniParser.cpp

Ты изначально спросил:

QSettings мне не понравился тем, что вывод в ini не очень читабелен. Посоветуйте альтернативу. (Лёгкую || совместимую с Qt) && удобно подключаемую && хорошо документированную.

Т.е. тебе настолько лень написать сотню строк на преобразование INI в QMap и наоборот, что ты принялся искать «готовое решение» и потом при попытке с помощи скотча и костылей прикрутить это «решение», ты тут же будешь всем выносить мозг на тему «плохой Qt». Сериализацию (и десериализацию) всегда писали исходя из конкретной практической надобности. Если бы ты написал, что «напишите мне сериализатор и десериализатор для INI, т.к. мне лень (я не умею)», то это было бы намного честнее того, что ты тут пытался изобразить - «не нравится не очень читабельный вывод» и не пришлось бы всем ответившим хернёй маятся.

А смысл? Оно не может глубже одной вложенности.

Зависит от того, как перегрузить/унаследоваться этот класс.

ну т.е. переписать половину, или вообще свое написать с нуля.

и такое уже не в первый раз - шаг влево шаг вправо из розового мирка кутеписателей - лучше написать с нуля. ощущение что кути пишет студентота. я не отрицаю что я тот еще лошпет в плюсах, но даже мне их детство ясно видно.

Почему же нет? А какой удобный (для многоуровневых иерархических настроек)?

Возможно, вы - мазохист и получаете особое удовольствие от написания очередного велосипеда в 100-ю строк вместо полезного кода, но почему вы считаете каждый обязан разделять вашу любовь к бесполезному труду?

Нет возможности комментировать. YAML лучше будет.

вопрос не про формат, а про сериализатор

Если тебе не «нравится» стандартное решение, то ты пишешь свой сериализатор. Но ты же предпочитаешь взять что-то левое, долго это прикручивать, и получить в результате непойми как работающее решение. Вместо 100 строк кода, который полностью решает твою проблему, втягивать несколько тысяч строк кода и всё равно делать обвязку. Вот это я понимаю - совершенно никакого мазохизма и никакого бесполезного труда.

не угадал

Ну вообще у использования библиотек есть свой плюс, в виде того что они тестируются лучше. Да, ты можешь сказать, что в 100 строках кода налажать, хе-хе. Но у тебя таких кусков по 100 строк кода много и в то что ты не делаешь ошибок я не верю.

Использование библиотеки Б оправдано, если в уже используемой библиотеке А нет нужного функционала. Тут явно не этот случай.

К тому же «QSettings мне не понравился тем, что вывод в ini не очень читабелен» говорит о вкусовщине, которая у каждого своя. Предполагается ли, что пользователи будут редактировать этот самый ini вручную? Если ответ «нет», то я вообще тогда не понимаю претензий.