json — & quot; Best & quot; Форматы входных файлов для C ++?

Я начинаю работу над новым программным обеспечением, которое в конечном итоге потребует надежного и расширяемого файлового ввода-вывода. Есть много форматов там. XML, JSON, INI и т. Д. Тем не менее, всегда есть плюсы и минусы, поэтому я подумал, что я хотел бы попросить мнение сообщества.

Вот некоторые грубые требования:

  1. Формат «стандартный» … Я не хочу изобретать велосипед, если мне не нужно. Это не обязательно должен быть формальный стандарт IEEE, но то, что вы могли бы использовать в Google и получить некоторую информацию как новый пользователь, может иметь некоторые инструменты поддержки (редакторы) помимо vi. (Хотя пользователи программного обеспечения, как правило, разбираются в компьютерах и будут рады использовать vi.)
  2. Легко интегрируется с C ++. Я не хочу брать с собой библиотеку объемом 100 Мб и три разных компилятора, чтобы запустить ее.
  3. Поддерживает табличный ввод (2d, n-мерный)
  4. Поддерживает типы POD
  5. Может расширяться, когда требуется больше входных данных, хорошо привязывается к переменным и т. Д.
  6. Скорость разбора не очень важна
  7. В идеале так легко написать (отразить), как читать
  8. Хорошо работает на Windows и Linux
  9. Поддерживает композитинг (один файл ссылается на другой файл для чтения и т. Д.)
  10. Человек читаемый

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

Итак, что вы думаете о различных форматах? Недостатки? Преимущества?

редактировать

Варианты для рассмотрения? Что-нибудь еще добавить?

  • XML
  • YAML
  • SQLite
  • Google Protocol Buffers
  • Повысить сериализацию
  • INI
  • JSON

18

Решение

Существует один отличный формат, который отвечает всем вашим критериям:

Пожалуйста, прочитайте статья об использовании SQLite в качестве формата файла приложения. Также пожалуйста смотреть Google Tech Talk Д. Ричард Хипп (автор SQLite) об этой самой теме.

Теперь давайте посмотрим, как SQLite отвечает вашим требованиям:

Формат «стандартный»

SQLite стал предпочтительным форматом для большинства мобильных сред и для многих настольных приложений (Firefox, Thunderbird, Google Chrome, Adobe Reader, как вы его называете).

Легко интегрируется с C ++

SQLite имеет стандартный интерфейс C, который является только одним исходным файлом и одним файлом заголовка. Есть C ++ оболочки.

Поддерживает табличный ввод (2d, n-мерный)

Таблица SQLite настолько таблична, насколько вы можете себе представить. Чтобы представить, скажем, трехмерные данные, создайте таблицу со столбцами x,y,z,value и сохраните ваши данные в виде набора строк следующим образом:

x1,y1,z1,value1
x2,y2,z2,value2
...

Поддерживает типы POD

Я предполагаю, что под POD вы имели в виду Plain Old Data или BLOB. SQLite позволяет хранить поля BLOB как есть.

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

Вот где это действительно светит.

Скорость разбора не очень важна

Но скорость SQLite превосходна. На самом деле разбор в основном прозрачный.

В идеале так легко написать (отразить), как читать

Просто используйте INSERT написать и SELECT читать — что может быть проще?

Хорошо работает на Windows и Linux

Вы делаете ставку, как и все другие платформы.

Поддерживает композитинг (один файл ссылается на другой файл для чтения)

Вы можете прикрепить одну базу данных к другой.

Человек читаемый

Не в двоичном виде, но есть много отличных браузеров / редакторов SQLite. мне нравится SQLite Expert Personal на Windows и sqliteman в линуксе Существует также Плагин редактора SQLite для Firefox.


Есть и другие преимущества, которые SQLite предоставляет вам бесплатно:

  • Данные индексируемая что делает поиск очень быстрым Вы просто не можете сделать это, используя XML, JSON или любые другие текстовые форматы.

  • Данные могут быть отредактированы частично, даже когда объем данных очень велик. Вам не нужно переписывать несколько гигабайт только для редактирования одного значения.

  • SQLite полностью транзакционный: это гарантирует, что ваши данные всегда согласованы. Даже если ваше приложение (или весь компьютер) дает сбой, ваши данные будут автоматически восстановлены до последнего известного согласованного состояния при следующей первой попытке подключения к базе данных.

  • SQLite хранит ваши данные дословный: вам не нужно беспокоиться об экранировании ненужных символов в ваших данных (включая нулевые байты, встроенные в ваши строки) — просто всегда используйте готовые заявления, это все, что нужно, чтобы сделать его прозрачным. Это может быть большой и раздражающей проблемой при работе с форматами текстовых данных, в частности с XML.

  • SQLite хранит все строки в Unicode: UTF-8 (по умолчанию) или UTF-16, Другими словами, вам не нужно беспокоиться о кодировках текста или международной поддержке вашего формата данных.

  • SQLite позволяет обрабатывать данные небольшими порциями (на самом деле строка за строкой), поэтому он хорошо работает в нехватка памяти. Это может быть проблемой для любых текстовых форматов, потому что часто им нужно загружать весь текст в память для его анализа. Конечно, существует несколько эффективных анализаторов XML на основе потоков, но в целом любой анализатор XML будет довольно жадным по сравнению с SQLite.

18

Другие решения

Проработав довольно много с XML и json, вот мое довольно субъективное мнение о обоих как расширяемых форматах сериализации:

  • Формат «стандартный»: да для обоих
  • Легко интегрируется с C ++: да для обоих. В каждом случае вам, вероятно, понадобится какая-нибудь библиотека для этого. В Linux libxml2 является стандартом, а libxml ++ — оболочкой для C ++; вы должны быть в состоянии получить оба из менеджера пакетов вашего дистрибутива. Потребуется небольшое усилие, чтобы заставить тех, кто работает на Windows. Похоже, что в Boost есть поддержка json, но я ее не использовал; Я всегда имел дело с JSON, используя библиотеки. Действительно, маршрут библиотеки не очень обременителен для обоих.
  • Поддерживает табличный ввод (2d, n-мерный): да для обоих
  • Поддерживает типы POD: Да для обоих
  • Может расширяться, поскольку требуется больше входных данных: Да, для обоих — это одно большое преимущество для них обоих.
  • Хорошо привязывается к переменным: если то, что вы имеете в виду, это как-то внутри самого файла сказать «это часть данных должна быть автоматически десериализована в этот переменная в моей программе «, то нет для обоих.
  • Писать (отражать) так же легко, как и читать: Зависит от используемой вами библиотеки, но, по моему опыту, да для обоих. (На самом деле вы можете сделать сносную работу по написанию json, используя printf ().)
  • Хорошо работает на Windows и Linux: да, как для MacOS X, так и для других.
  • Поддерживает один файл, ссылающийся на другой файл, для чтения: если вы имеете в виду что-то похожее на C #include, то XML имеет некоторые возможности для этого (например, объекты документов), а json — нет.
  • Удобный для чтения: оба, как правило, написаны на UTF-8 и допускают разрывы строк и отступы, и, следовательно, могут быть удобочитаемыми. Тем не менее, я только что работал с файлом XML объемом 479 КБ, который находится в одной строке, поэтому мне пришлось пробовать его через симпатичный принтер, чтобы разобраться в этом. json также может быть довольно нечитаемым, но, по моему опыту, он часто форматируется лучше, чем XML.

При запуске новых проектов я обычно предпочитаю json; это более компактно и более читабельно. Основной причиной, по которой я мог бы выбрать XML вместо json, было бы то, что я беспокоился о получении плохо сформированных документов, так как XML поддерживает автоматическую проверку формата документов, в то время как вы должны написать свой собственный код проверки с помощью json.

8

Проверять, выписываться Google Buffers. Это обрабатывает большинство ваших требований.

Из их документации, шаги высокого уровня:

Определите форматы сообщений в .proto файле.
Используйте компилятор протокола буфера.
Используйте API буфера протокола C ++ для записи и чтения сообщений.

4

Для моих целей я думаю, что путь XML.

  1. Формат является стандартным, но позволяет изменять и гибко изменять схему по мере изменения требований к программе.
  2. Есть несколько вариантов библиотеки. Некоторые больше (Xerces-C), некоторые меньше (ezxml), но есть много вариантов, поэтому мы не будем привязаны к одному провайдеру или очень конкретному решению.
  3. Он может поддерживать табличный ввод (2d, n-мерный). Это требует больше разбора на «нашем» конце и, вероятно, является самым слабым местом для XML.
  4. Поддерживает типы POD: Абсолютно.
  5. Может расширяться, когда требуется больше входных данных, хорошо привязывается к переменным и т. Д. Посредством модификаций схемы и парсера.
  6. Скорость разбора не очень важна, поэтому обработка текстового файла или файлов не является проблемой.
  7. XML может быть программно написан так же легко, как и прочитан.
  8. Хорошо работает на Windows и Linux или любой другой ОС, которая поддерживает C и текстовые файлы.
  9. Поддерживает композитинг (один файл ссылается на другой файл для чтения и т. Д.)
  10. Удобный для чтения многими текстовыми редакторами (Sublime, vi и т. Д.), Поддерживающими подсветку синтаксиса «из коробки». Многие веб-браузеры хорошо отображают данные.

Спасибо за все отличные отзывы! Я думаю, что если бы мы хотели получить чисто двоичное решение, то, скорее всего, мы бы выбрали протокол Protocol Buffers или boost :: serialization.

-6
По вопросам рекламы [email protected]