"Лучшие" форматы входных файлов для С++?
Я начинаю работу над новым программным обеспечением, которое в конечном итоге потребует некоторого надежного и расширяемого файла ввода-вывода. Там много форматов. XML, JSON, INI и т.д. Однако всегда есть плюсы и минусы, поэтому я подумал, что попрошу внести некоторые предложения сообщества.
Вот некоторые грубые требования:
- Формат является "стандартным"... Я не хочу изобретать велосипед, если мне это не нужно. Он не должен быть формальным стандартом IEEE, но что-то, что вы могли бы сделать Google и получить некоторую информацию в качестве нового пользователя, может иметь некоторые инструменты поддержки (редакторы) за пределами vi. (Хотя пользователи программного обеспечения, как правило, понимают компьютер и с удовольствием используют vi.)
- Легко интегрируется с С++. Я не хочу, чтобы вытащить библиотеку 100mb и три разных компилятора, чтобы запустить ее и запустить.
- Поддержка табличного ввода (2d, n-мерный)
- Поддержка типов POD
- Может расширяться по мере необходимости в дополнительных вводах, хорошо связывается с переменными и т.д.
- Скорость обработки не очень важна.
- В идеале, как легко писать (отражать), так как читать
- Хорошо работает в Windows и Linux
- Поддержка композитинга (один файл ссылается на другой файл для чтения и т.д.)
- Человек, читаемый
В идеальном мире я бы использовал библиотеку только для заголовков или некоторую чистую реализацию STL, но я в порядке с использованием Boost или небольшой внешней библиотеки, если она работает хорошо.
Итак, что вы думаете о разных форматах? Недостатки? Преимущества?
Edit
Параметры для рассмотрения? Что еще добавить?
- XML
- YAML
- SQLite
- Буферы протокола Google
- Последовательность обновления
- INI
- JSON
Ответы
Ответ 1
В моих целях, я думаю, что путь - XML.
- Формат является стандартным, но позволяет изменять и гибко изменять схему при изменении требований к программе.
- Существует несколько вариантов библиотеки. Некоторые из них больше (Xerces-C), некоторые из них меньше (ezxml), но есть много вариантов, поэтому мы не будем привязаны к одному провайдеру или очень конкретному решению.
- Он может поддерживать табличный ввод (2d, n-мерный). Это требует большей обработки синтаксического анализа "нашего" конца и, вероятно, является самой слабой точкой для XML.
- Поддерживает типы POD: Абсолютно.
- Может расширяться по мере необходимости в дополнительных вводах, хорошо связывается с переменными и т.д. с помощью модификаций схемы и модификаций анализатора.
- Скорость обработки не очень важна, поэтому обработка текстового файла или файлов не является проблемой.
- XML можно программировать так же легко, как и читать.
- Хорошо работает в Windows и Linux или любой другой ОС, поддерживающей C и текстовые файлы.
- Поддержка композитинга (один файл ссылается на другой файл для чтения и т.д.)
- Чтение человеком со многими текстовыми редакторами (Sublime, vi и т.д.), поддерживающее подсветку синтаксиса. Многие веб-браузеры хорошо отображают данные.
Спасибо за отличную обратную связь! Я думаю, что если бы мы хотели чисто двоичное решение, буферы протоколов или boost:: serialization, вероятно, были бы такими, как мы могли бы пойти.
Ответ 2
Существует один отличный формат, который соответствует всем вашим критериям:
SQLite!
Прочитайте статью об использовании SQLite в качестве формата файла приложения. Кроме того, пожалуйста, просмотрите Google Tech Talk от D. Richard Hipp (автор SQLite) по этой теме.
Теперь давайте посмотрим, как SQLite отвечает вашим требованиям:
Формат является "стандартным"
SQLite стал форматом выбора для большинства мобильных сред и для многих настольных приложений (Firefox, Thunderbird, Google Chrome, Adobe Reader, вы называете его).
Легко интегрируется с С++
SQLite имеет стандартный интерфейс C, который является только одним исходным файлом и одним файлом заголовка. Есть обертки С++ тоже.
Поддерживает табличный ввод (2d, n-мерный)
Таблица SQLite такая же табличная, как вы могли себе представить. Чтобы представить 3-мерные данные, создайте таблицу с столбцами 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 on Linux. Существует также плагин редактора SQLite для Firefox.
Существуют и другие преимущества, предоставляемые SQLite:
-
Данные индексируются, что делает его очень быстрым для поиска. Вы просто не можете сделать это, используя XML, JSON или любые другие текстовые форматы.
-
Данные могут быть отредактированы частично, даже если количество данных очень велико. Вам не нужно переписывать несколько гигабайт только для редактирования одного значения.
-
SQLite полностью транзакционный: он гарантирует, что ваши данные будут постоянными. Даже если ваше приложение (или весь компьютер) выйдет из строя, ваши данные будут автоматически восстановлены до последнего известного согласованного состояния при следующей первой попытке подключения к базе данных.
-
SQLite хранит ваши данные verbatim: вам не нужно беспокоиться об экранировании нежелательных символов в ваших данных (включая нулевые байты, встроенные в ваши строки) - просто всегда используйте подготовленные заявления, что все, что требуется, чтобы сделать его прозрачным. Это может быть большой и раздражающей проблемой при работе с текстовыми форматами данных, в частности XML.
-
SQLite хранит все строки в Unicode: UTF-8
(по умолчанию) или UTF-16
. Другими словами, вам не нужно беспокоиться о текстовых кодировках или международной поддержке вашего формата данных.
-
SQLite позволяет обрабатывать данные в небольших кусках (по сути, строка), поэтому она хорошо работает в условиях низкой памяти. Это может быть проблемой для любых текстовых форматов, потому что часто им приходится загружать весь текст в память для его анализа. Конечно, существует несколько эффективных XML-парсеров на основе потоков, но в целом любой синтаксический анализатор XML будет довольно жадным по сравнению с SQLite.
Ответ 3
Поработав совсем немного с XML и json, здесь мое довольно субъективное мнение как в виде расширяемых форматов сериализации:
- Формат является "стандартным": Да для обоих
- Легко интегрируется с С++: Да для обоих. В каждом случае вы, вероятно, соберете какую-то библиотеку для ее обработки. В Linux libxml2 является стандартом, а libxml ++ - это С++-оболочка; вы должны иметь возможность получить оба из своего менеджера дистрибутива. Для того, чтобы работать с Windows, потребуется немного усилий. По-видимому, в Boost есть определенная поддержка для json, но я не использовал ее; Я всегда разбирался с json, используя библиотеки. На самом деле, маршрут библиотеки не слишком обременителен для.
- Поддержка табличного ввода (2d, n-мерный): Да для обоих
- Поддерживает типы POD: Да для обоих
- Может расширяться по мере ввода большего количества входов: Да для обоих - это одно большое преимущество для обоих из них.
- Хорошо подходит для переменных: если вы имеете в виду какой-то способ внутри самого файла, чтобы сказать: "Эта часть данных должна быть автоматически десериализована в эту переменную в моей программе", то нет для обоих.
- Как легко писать (отражать), так как он читается: зависит от используемой библиотеки, но по моему опыту да для обоих. (Вы действительно можете выполнять переносимую работу по написанию json с помощью printf().)
- Хорошо работает в Windows и Linux: да и для Mac, и для Mac OS X.
- Поддерживает один файл, ссылающийся на другой файл: Если вы имеете в виду что-то похожее на С#include, то XML имеет некоторую возможность сделать это (например, объекты документа), а json - нет.
- Чтение человеком: оба они обычно пишутся в UTF-8 и разрешают разрывы строк и отступы и, следовательно, могут быть удобочитаемыми для человека. Тем не менее, я только что работал с XML файлом размером 479 КБ, который все на одной строке, поэтому мне пришлось запустить его через симпатичный принтер, чтобы понять это. json также может быть довольно нечитаемым, но в моем опыте часто форматируется лучше, чем XML.
При запуске новых проектов я обычно предпочитаю json; он более компактный и читаемый человеком. Основная причина, по которой я могу выбрать XML над json, была бы, если бы я беспокоился о получении плохо сформированных документов, поскольку XML поддерживает автоматическую проверку формата документа, в то время как вы должны написать свой собственный код проверки с помощью json.
Ответ 4
Проверьте буферы Google. Это отвечает большинству ваших требований.
Из документации, шаги высокого уровня:
Определить форматы сообщений в файле .proto.
Используйте компилятор буфера протокола.
Используйте API буфера протокола С++ для записи и чтения сообщений.