Я начинаю работу над новым программным обеспечением, которое в конечном итоге потребует надежного и расширяемого файлового ввода-вывода. Есть много форматов там. XML, JSON, INI и т. Д. Тем не менее, всегда есть плюсы и минусы, поэтому я подумал, что я хотел бы попросить мнение сообщества.
Вот некоторые грубые требования:
В идеальном мире я бы использовал библиотеку только для заголовков или какую-то чистую реализацию STL, но я в порядке, используя Boost или небольшую внешнюю библиотеку, если она работает хорошо.
Итак, что вы думаете о различных форматах? Недостатки? Преимущества?
редактировать
Варианты для рассмотрения? Что-нибудь еще добавить?
Существует один отличный формат, который отвечает всем вашим критериям:
Пожалуйста, прочитайте статья об использовании 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.
Проработав довольно много с XML и json, вот мое довольно субъективное мнение о обоих как расширяемых форматах сериализации:
При запуске новых проектов я обычно предпочитаю json; это более компактно и более читабельно. Основной причиной, по которой я мог бы выбрать XML вместо json, было бы то, что я беспокоился о получении плохо сформированных документов, так как XML поддерживает автоматическую проверку формата документов, в то время как вы должны написать свой собственный код проверки с помощью json.
Проверять, выписываться Google Buffers. Это обрабатывает большинство ваших требований.
Из их документации, шаги высокого уровня:
Определите форматы сообщений в .proto файле.
Используйте компилятор протокола буфера.
Используйте API буфера протокола C ++ для записи и чтения сообщений.
Для моих целей я думаю, что путь XML.
Спасибо за все отличные отзывы! Я думаю, что если бы мы хотели получить чисто двоичное решение, то, скорее всего, мы бы выбрали протокол Protocol Buffers или boost :: serialization.