Расскажите про XML

Для твоей задачи XML не нужен вовсе.

Может стоит попробовать JSON?

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

И что за язык то?

Задают вопрос про структуру здания, где расположить гаражи. Лисперы в ответ спрашивают, какая марка у бетономешалки.

Угу, потому что лучше использовать уже готовое решение (какое зависит от языка) и самому ничего не строить. Нет?

Да, есть, perl, store, load. Ну и по желанию есть модули для сериализации во что захочешь:)

У структуры с параметрами можно сделать методы Load и Save. А в них уже писать в файлы, БД и куда угодно. А файлы можно простые типа ключ-значение. Для иерархических данных XML.

Если не секрет, то почему не нужен XML? И что я делаю не так. Тоесть ощущение что я что-то делаю не так, у меня возникло, поэтому тут и спрашиваю.

У меня несколько десятков параметров, которые мне нужно писать/читать.

У тебя там дерево?

XML только для сложных иерархических настроек. Пример (хотя и не самый удачный) - файлы интерфейсов в Qt Designer и GtkBuilder/Glade.

Для всего остального идеально подходят обычные файлы поле-значение (в винде называемые INI-файлы).

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

ОЧЕНЬ не хочется делать бинарный конфиг, и хочется иметь возможность иметь какие-то комментарии. Или хотя бы документацию, что и зачем в том XML.

И ну ОЧЕНЬ не хочется ловить во всем этом глюки.

INI, это конечно здово, но хочется переносимости. Пусть в ущерб удобству, но точно не в ущерб глюкавости. Если посреди floatа окажется какой-то символ, и оно будет считываться с ошибкой, (к примеру) мне будет очень не приятно. В общем на первом месте безглючность. Но хочется проконтролировать и попытку загрузки float в int, а int во float, так и к примеру неправильно набранное имя параметра итд.

Но будь добр, признайся что за платформа и язык. В .NET/Mono, Java, Qt, Glib для этого есть готовые вещи. Может в вашей платформе есть готовое.

Та linux/плюсы. Про библиотеки для конфигов я в курсе. Сам пользуюсь. Я просто не сильно хорошо понимаю что даст XML. Пока получается очень криво. Мне не нравится.

Для С++ можно взять xerces,tinyxml,RapidXml.

Язык то какой? Помоему для всех более или менее вменяемых языков есть средства, делающие работу с настройками прозрачной до усёру.

По идее криво получается.

Конечно.

>Я просто не сильно хорошо понимаю что даст XML

Удобно лишь для сложно структурированных данных. Если структура простая, то он XML не нужен.

>> Я просто не сильно хорошо понимаю что даст XML

Так тебе шашечки или ехать? Конкретно в твоем случае XML не даст ничего, т.к. ты собрался работать с ним «в живую». Какая разница какой велосипед изобретать?

Всё ясно, XML тут самое оно.

Одевко не знаю на сколько целесообразен тут DOM. DOM предпочтительно создавать на всё время работы пиложения.

> Всё ясно, XML тут самое оно.

Ну и чем тут XML будет лучше той же libconfig? Ничем, он здесь не нужен. Использовать XML для конфигов это маразм.

>Использовать XML для конфигов это маразм.

Ты видимо некоторые конфиги не видел. Мне доводилось писать ПО для контроллера, которое считывало XML файл с конфигурацией. При этом структура конфигурации была очень сложна и в ходе эволюции ПО существенно изменялась. XML файл создавала отдельная программа с GUI. Затраты на написание кода, ответственного за создание/запись/считывание конфигурации были не велики и код хорошо подвергался переделке. В итоге я остался доволен решением взять XML за основу, т.к. я в живую убедился в его полезности.

что люди только не делают, лишь бы не использовать s-выражения... =)

> Ты видимо некоторые конфиги не видел

Надо полагать, что да, не все. Только чем в данном случае XML лучше чем libconfig? Именно для конфигов у libconfig и функционала больше, и пользоваться ей значительно более приятно

Я просто не сильно хорошо понимаю что даст XML

Я считаю, что XML стоит применять в одном из следующих случаев:

* Важен/полезен механизм пространств имён
* Важная роль отводится языку запросов XPath
* Для обработки документа будет использовать XSTL
* В (очень) редких случая, когда DOM API хорошо ложится на решаемую задачу

В прочих лучших случаях JSON будет более лучшим решением, а в специальных (типа конфигов) ещё лучше использовать специализированные решения.

> что люди только не делают, лишь бы не использовать s-выражения... =)

Не стоит пихать s-выражения куда ни поподя, тем более, что в «не лисп» языках пользоваться ими, даже если написать парсер, будет банально не удобно.

> Не стоит пихать s-выражения куда ни поподя, тем более, что в «не лисп» языках пользоваться ими, даже если написать парсер, будет банально не удобно.

как раз-таки вместо xml было бы в самый раз. а что неудобного в парсинге s-выражений? по-моему так наоборот, весьма просто

> как раз-таки вместо xml было бы в самый раз.

s-выражения не являются какой либо альтернативой xml

а что неудобного в парсинге s-выражений?

Разве я сказал в парсинге? Я сказал в использовании. Распаренное s-выражение является, вообще говоря, деревом, построенным на основе списков. В лиспе есть богатый набор инструментов, для работы с подобными структурами, но его нет в других языках.

>Только чем в данном случае XML лучше чем libconfig?

XML поддерживается везде где только можно. В моем случае GUI программа-конфигуратор использовала родной для .NET парсер XML. Использовать что-то другое, когда есть удобный парсер «искаропки» ИМХО глупо.

Проще говоря парсер легче найти под разные платформы.

google json vs xml. У всех своё мнение

> XML поддерживается везде где только можно.

Проблема в том, что DOM не является удобным API для доступа к произвольным элементам дерева, а пользоваться XPath могут не многие. В итоге, типично overhead совершенно не соответствует решаемой задачи.

> google json vs xml. У всех своё мнение

JSON это прежде всего формат, а XML прежде всего технология. И лучше не использовать XML как просто формат.

>Проблема в том, что DOM не является удобным API для доступа к произвольным элементам дерева

Ну может в твои слова не лишены смысла. Хотя у меня эта проблема никогда не всплывала в силу особенностей моего софта. В моем случае стиль DOM казался удобнее всего. Но похоже действительно есть ситуации когда удобнее использовать что-то другое.

Храни в БД. Например sqlite. Или sqlite.net

> Храни в БД. Например sqlite. Или sqlite.net

а как будешь организовывать иерархию + разделение по типам?

>И лучше не использовать XML как просто формат.

У XML есть некоторые преймущества. Главное это валидация по различным схемам, предотвращает многие способы «пристрелить ногу». Так же его удобно просматривать в браузерах, прикрутив CSS и XSLT.

Если это не используется, то XML тут не нужен.

Вообще если ты сказал, что это только конфиги и ты пишешь на С++, то конечно прямой пользы от XML нету. Например классы на .NET или Java могут serialize в произвольный XML документ. Более того в них есть специальный класс для хранения настроек, имеющий возможности хранения в XML формате.

Если ты пишешь на C++, то для десктопных приложений на Qt есть QSettings. Отличное решение, на винде хранит в реестре, на юникс в других конфигах, кажется INI

Для G* приложений есть мощнейшее решение - gconf, там для хранения настроек предусмотрели все. И попроще «Key-value file parser» (смотри в Devhelp по glib).

Если выберешь хранить XML - не прогадаешь тоже. Он читаем, стандартен и очень мощный

> У XML есть некоторые преймущества.

Ну я же указал выше случаи, когда имеет смысл его использовать, да, про валидацию забыл, наверное потому, что всего раз видел пример успешного её применения на практике.

> Если выберешь хранить XML - не прогадаешь тоже.

Он читаем, стандартен и очень мощный

Что такое «мощный»? В нём даже массивов нет, а JSON есть, так кто мощнее для конфига?

>В нём даже массивов нет

Это не мешает в XML хранить массив данных, что я собственно и делал много раз.

> Это не мешает в XML хранить массив данных,

что я собственно и делал много раз.

Ну, не то что не мешает, но обойти можно разным путями. Суть ведь не в этом, а в том, что используя другие средства можно решить проблемы проще и с меньшим напрягом.

>В нём даже массивов нет.

А тут можно поподробней? Как это нет?

> А тут можно поподробней? Как это нет?

Как можно подробно рассказывать о том, чего нет?

А то что элемент сам по себе масив узлов и в дополнение к этому хеш строковых значений по парам строк в качестве ключей не смущает? Или я не так понял?

А тут можно поподробней? Как это нет?

Видимо имелось в виду, что в базовом XML (про XSLT/XPATH мало что знаю) нет специального синтаксиса для описания массивов. Но всегда можно описать что-то вроде

<SomeArray>
  <SomeArrayItem />
  <SomeArrayItem />
  <SomeArrayItem />
  <SomeArrayItem />
  <SomeArrayItem />
</SomeArray>

<SomeArrayItem />
<SomeArrayItem />
<SomeArrayItem />
<SomeArrayItem />
<SomeArrayItem />

> А то что элемент сам по себе масив узлов

Список узлов, который включает в себя в том числе текстовые, инструкции обработки и т.п.

и в дополнение к этому хеш строковых значений

по парам строк в качестве ключей не смущает

Чего? Вот теперь я уже не понял, о чём речь.

Некоторые масивы можно просто пречислить через пробельный символ, в XSD они так тоже описываются. С таким подходом есть трудности в XPath1 потому я бы так делать не стал.

>> и в дополнение к этому хеш строковых значений

по парам строк в качестве ключей не смущает

Чего? Вот теперь я уже не понял, о чём речь.

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

> Речь про атрибуты, каждый из которых в пределах элемента уникален

и задаётся именем и пространствос имён.

Ну и при чём тут массивы?

>Ну и при чём тут массивы?

Атрибуты элемента можно представить как ассоциативный контейнер вида: map<string,string> attributes. Не массив конечно, но в некоторых случаях может сойти.

Поменьше надо уровней иерархии

JSON даёт это всё из коробки. XML это язык для публикации, а не для конфигов.