C++, хочу парсер простого текстового формата написать.

Проблема XML: Если ты написал:

<list>
   <ha id="1"/>
   <ha id="2"/>
   <ha id="3"/>
</list>

А нормальные люди ваще юзают YAML:

list:
 - ha
 - ha
 - ha

или его подмножество - язык JSON:

{ list: [ "ha", "ha", "ha" ] }

При этом гарантируется порядок следования элементов «ha». Ибо список - встроенное понятие YAML.

Даже не знаю что это.

то-то же :) Достижение: узнал знакомые слова в xml файле! Отлично-чиаемый формат, ага.

А добавить координату в список сможешь, чтобы программа потом не сломалась?

И что ты про оверхед сказал, я не расслышал?

А у топикстартера уже всё работет, как я понимаю.

У него проблемы не с JSON, а с реализацией. Ты отдаешь себе отчет, что это разные понятия?

То библиотека, загружающая этот XML по стандарту не обязана выдать пользователю элементы «ha» в том порядке

можно ссылку на абзац стандарта?

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

<settings xmlns="http://maven.apache.org/SETTINGS/1.0.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://maven.apache.org/SETTINGS/1.0.0 http://maven.apache.org/xsd/settings-1.0.0.xsd">
</settings>


Даже если редактор не знает про namespace http://maven.apache.org/SETTINGS/1.0.0 , он может сходит по адресу http://maven.apache.org/xsd/settings-1.0.0.xsd скачать схему и получить логическую валидацию + автокомплит по тегам.

Если это не удобно, то не знаю чего такое удобно.

Ты прочитал в сообщении только то что хотел прочитать это первый признак фанатика.
Во-первых, ты привел в пример не валидный xml. В xml не может быть несколько рутовых тегов.
Во-вторых, я тебе отредактировал xml. Ты ничего не сможешь сделать в json, пока полностью не поймёшь внутреннию логику - что на что влияет.
В-третьих, «узнал знакомые слова в xml файле! Отлично-чиаемый формат, ага.» это выражает всего лишь твою беспомощность в попытке доказать свое глупое мнение.
Ну и в последних, «И что ты про оверхед сказал, я не расслышал?» про оверхед рассуждают люди, которые обычно никогда не анализировали влияние этого самого ужасного оверхеда и да, обычно, это заносчивые студенты без какого-либо опыта.

У него проблемы не с JSON, а с реализацией. Ты отдаешь себе отчет, что это разные понятия?

lol, конечно, у чувака нет проблем с json, он у него тупо не заработал как ему надо и чувак полез изобретать формат сериализации. в 2013 году.

Все ясно. Если я напишу библиотеку json.cpp, и все, что она будет делать - возвращать 0, то это тоже JSON плохой.

Все ясно. Если я напишу библиотеку json.cpp, и все, что она будет делать - возвращать 0, то это тоже JSON плохой.

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

Пиши баг репорт разработчикам boost::serialization, если ты считаешь, что они не правы - это выхлоп библиотеки.

про оверхед рассуждают люди, которые обычно никогда не анализировали влияние этого самого ужасного оверхеда

что тут анализировать, если просто очевидно что xml очень громоздок.

у меня даже есть пример: гугл перетащил свои core reporting api на json и сказал, что у них благодаря этому размер ответов уменшился в 10 раз. пруф из доки про core reporting api: https://developers.google.com/analytics/resources/articles/gdata-migration-guide

New Features

New JSON based output reduces the size of the response ~10x from the previous XML output. Тебе ещё какой-то анализ нужен?!

И да, говоря о фанатиках, не рефлексируй, ага.

У меня аргументы, у тебя одни обвинения в фанатизме. Так кто фанатик?

То библиотека, загружающая этот XML по стандарту не обязана выдать пользователю элементы «ha» в том порядке, в котором они перечислены в XML.

Если ты переводишь XML -> DOM, то в нём будет нужный порядок

A node list object represents a list of nodes, in the same order as in the XML.

гугл перетащил свои core reporting api на json

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

У меня аргументы, у тебя одни обвинения в фанатизме. Так кто фанатик?

lol Пока я обнаружил у тебя только один аргумент и он не совсем в тему. Пока ты :D :D

Пока я обнаружил у тебя только один аргумент

Два: xml имеет вырвиглазный синтаксис плохочитаем и xml громоздок и имеет большой оверхед.

про оверхед рассуждают люди, которые обычно никогда не анализировали влияние этого самого ужасного оверхеда

New JSON based output reduces the size of the response ~10x from the previous XML output.

молодцы, только какое это имеет тут значение?

по пункту «оверхед» слив засчитан.

Конечно всё ясно - оно будет не валидно, а у чуваков валидный json сериализатор. чуваки не зря извращаются с \uXXXX, потому что им явно не могло прийти в говору, что выхлоп их сериализатора может кому-то понадобится редактировать. Это надо действительно хорошо головой приложится :D.

Мдя ... И это пишет якобы не фанатик, никогда не имел дела со структурами данных, но пыжится и повторяет, как попка ахинею. Иди редактируй свой json не буду мешать.

А это уже, я так понима, из категорри «когда кончаются аргументы...».

может кому-то понадобится редактировать

Просто чуваки в США живут, для них русский язык и прочие, которым нужны символы выше 127 - языки ущербных вымирающих недолюдей. Пространство выше 127 для них - грязный сарай для псевдографики и всякой хрени. А родной американский язык в таком json очень хорошо редактируется, прям ваще супер - удобнее, чем в XML.

Ну ещё конечно существует рассчёт на то, что истинная кросс-платформенность в сериализации объектов - это рассчёт на 7-битные системы. Незнаю в каких музеях они сохранились, но чё-то я читал про Internet Explorer - какие-то у него проблемы с 8-битным json-ом... Но сам по себе IE - программулина ещё та, так что даже незнаю...

То есть, если забить болт на 7-битные системы и понять, что типа 21 век на дворе, то UTF-8 без всяких \uXXXX пишется в файл с экранированием некоторых символов, типа \".

Обязана по стандарту сохранить порядковый номер элемента иначе xpath бы не работал. Вот удивляют люди который пишут json/yaml - круто, xml - фигня, при этом ничего не знаю про стек xml технологий.

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

Еще один клоун. По-твоему, своеобразная реализация библиотеки имеет какое-то отношение к стандарту?

Мне кажется, знание порядкового номера элемента - это фишка xpath, а не обязанность XML.

Пшла вон, малолетняя безопытная гавкающая шавка.

Хотел в json сохранять - заюзал boost::property_tree::write_json().

Тебе нужен rapidjson или любая другая либа для чтения-записи JSOn

Но через текстовый редактор неудобно зырить на это мясо.

sqlitebrowser

Это у тебя такой батхерт оттого, что я прав, или от того, что я ткнул тебя носом в твою лажу?

Прогресс ушёл дальше первого поста - нужная либа найдена и всё прекрасно с json стало. sqlitebrowser есть сущность лишняя.

охо хох

во времена стародавнии теперь уже былиные был формат COMMENT TERM_WORD anything_but_term_word* TERM_WORD в тот же баш это проникло в виде HEREDOC

зачем длину хранить - которая и менятся может

не проще:

(слово_терминатор чтоугодно_без_этого слова слово_терминатор)*

т.е каждая строка окавычена идентичным словом_терминатором - для каждой строки слово таково что не содежрится в ней - поэтому обычно это может быть " для строк содержащих " может быть ' для строк содержащих " и ' может быть № и так далее короче рэндом скобки