Кроссплатформенная и языковая (де) сериализация

Question

Я ищу способ сериализации множества структур C ++ наиболее удобным способом, чтобы сериализация была переносимой на C ++ и Java (как минимум), а также на 32-битные / 64-битные платформы с прямым и прямым порядком байтов. Структурируемые структуры просто содержат данные, то есть они являются чистыми объектами данных без состояния или поведения.

Идея состоит в том, что мы сериализуем структуры в октетный BLOB-объект, который мы можем сохранить в базе данных «в общем» и прочитать позже. Таким образом, избегая изменения базы данных всякий раз, когда изменяется структура, а также избегая назначения каждого элемента данных полю - то есть мы хотим, чтобы только одна таблица содержала все «в общем» как двоичный двоичный объект. Это должно сделать меньше работы для разработчиков и потребовать меньше изменений при изменении структуры.

Я смотрел на boost.serialize, но не думаю, что есть способ обеспечить совместимость с Java. И также для наследования Serializable в Java.

Если есть способ сделать это, начав с файла IDL, который был бы наилучшим, поскольку у нас уже есть файлы IDL, описывающие структуры.

Ура заранее!

Answer 1

Если я действительно хочу использовать несколько языков, я обычно рекомендую JSON в качестве простоты поддержки javascript и изобилия библиотек , а также удобочитаемости и изменения для человека (я предпочитаю XML, как мне кажется, меньше с точки зрения символов, быстрее и более читабелен). Это не самый эффективный с точки зрения пространства, однако, и более машиночитаемый формат, такой как буфер протокола или thrift , будет иметь преимущества (экономия может быть сделана из IDL, но это также предназначен для служб кодирования, поэтому он может быть тяжелее, чем вы хотите).

Answer 2

Я удивлен, что Джон Скит еще не набросился на это: -)

Буферы протокола в значительной степени разработаны для такого рода сценариев - передачи структурированных данных на нескольких языках.

Тем не менее, если вы используете базу данных так, как вы предлагаете, вам действительно следует использовать не полнофункциональную СУБД, такую ​​как Oracle или SQL Server, а скорее легкое хранилище значений ключей, такое как Berkeley DB или множество «облачных таблиц» двигателей.

Answer 3

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

Есть много альтернатив, к сожалению, без явного победителя (хотя можно утверждать, что JSON - явный победитель). Даже Google выпустил несколько конкурирующих технологий (очевидно, все они используются внутри компании):

• FlatBuffers : этот, кажется, соответствует требованиям исходного вопроса, имеет интересные тесты и поддерживает некоторую форму IDL (лично я не знакомы с IDL)
• Буферы протокола : упоминалось ранее.
• XFJSON : на 5% -12% меньше, чем JSON.

Не забывать альтернативы, опубликованные в других ответах. Вот еще несколько:

• YAML : JSON минус все двойные кавычки, но вместо этого используется отступ. Он более читабелен, но, вероятно, менее эффективен, особенно когда он становится больше.
• BSON (двоичный JSON)
• MessagePack (еще один сжатый JSON)

С таким большим количеством вариантов JSON, несомненно, является победителем с точки зрения простоты / удобства и кроссплатформенного доступа. За последние пару лет он приобрел еще большую популярность благодаря росту JavaScript. Многие люди, вероятно, используют это как де-факто решение, не задумываясь об этом (это то, что я изначально делал: P).

Однако, если размер становится проблемой, но вы предпочитаете сохранять простоту и не использовать одну из более продвинутых библиотек, вы можете просто сжать JSON, используя zlib (это то, что я делаю сейчас), или какой-то другой кроссплатформенный алгоритм (но это совсем другая тема).

Чтобы ускорить обработку JSON в C ++, вы также можете использовать RapidJSON .

Answer 4

Я бы предложил сохранить данные в базе данных SQLite . Структуры могут быть сохранены как строки базы данных в таблицах SQLite.

Полученный файл базы данных является двоично-совместимым на многих различных платформах и может быть сохранен как BLOB в вашей основной базе данных. Я считаю, что размер файла сопоставим со сжатым файлом XML с теми же данными, но использование памяти во время обработки будет значительно меньше, чем XML DOM.

Answer 5

Вам нужно ASN.1 ! (Некоторые люди называют это двоичным XML.) ASN.1 очень компактен и поэтому идеально подходит для передачи данных между двумя системами. И для тех, кто не думает, что это когда-либо использовалось: несколько интернет-протоколов основаны на модели ASN.1 для сериализации данных!

К сожалению, для Java или C ++ не так много библиотек, поддерживающих ASN.1. Мне пришлось работать с ним несколько лет назад, и я просто не смог найти хорошего, бесплатного или недорогого инструмента, который бы позволял поддерживать ASN.1 в C ++. На Objective Systems они продают решения ASN.1 / XML, но это чрезвычайно дорого. (Компилятор ASN.1 для C ++ и Java, то есть!) Это стоит вам как минимум руки и ноги! (Но тогда у вас будет инструмент, который вы сможете использовать только одной рукой ...)

Answer 6

Почему вы не выбрали XML, так как это идеально соответствует вашим требованиям. И C ++, и Java допускают простую реализацию.

Кроме того, я сомневаюсь в вашей идее хранить все как блоб в базе данных, использовать реляционную базу данных, для которой была разработана база данных, или переключаться на какую-либо объектно-ориентированную базу данных, например http://www.versant.com/en_US/products/objectdatabase, которая поддерживает как Java, так и C ++.

Answer 7

Существует также Avro. Посмотрите этот вопрос для сравнения экономии Apache, буферов протокола, mes и т. Д.