mpack
v1.1.1
MPACK - это C -реализация кодера и декодера для формата сериализации MessagePack. Это:
Ядро MPACK содержит буферный читатель и писатель, а также анализатор в стиле дерева, который декодирует в дерево динамически напечатанных узлов. Помощные функции могут быть включены для чтения значений ожидаемого типа, для работы с файлами, для автоматического выращивания буферов или автоматического распределения строк, чтобы проверить кодирование UTF-8 и многое другое.
Код MPACK достаточно мал, чтобы быть встроенным непосредственно в вашу кодовую базу. Просто загрузите пакет Amalgamation и добавьте mpack.h и mpack.c в ваш проект.
MPACK поддерживает все современные компиляторы, все настольные и смартфоны, Webassembly, внутри ядра Linux и даже 8-битные микроконтроллеры, такие как Arduino. MPACK STEAST можно настроить во время компиляции, чтобы установить, какие функции, компоненты и проверки отладки составлены, и какие зависимости доступны.
API узла анализирует кусок данных MessagePack в неизменное дерево с динамически типичными узлами. Серия вспомогательных функций может использоваться для извлечения данных определенных типов из каждого узла.
// parse a file into a node tree
mpack_tree_t tree ;
mpack_tree_init_filename ( & tree , "homepage-example.mp" , 0 );
mpack_tree_parse ( & tree );
mpack_node_t root = mpack_tree_root ( & tree );
// extract the example data on the msgpack homepage
bool compact = mpack_node_bool ( mpack_node_map_cstr ( root , "compact" ));
int schema = mpack_node_i32 ( mpack_node_map_cstr ( root , "schema" ));
// clean up and check for errors
if ( mpack_tree_destroy ( & tree ) != mpack_ok ) {
fprintf ( stderr , "An error occurred decoding the data!n" );
return ;
}Обратите внимание, что в приведенном выше коде нет дополнительной обработки ошибок. Если файл отсутствует или поврежден, если ключи карт отсутствуют или если узлы не находятся в ожидаемых типах, возвращаются специальные узлы «ноль» и значения false/Zero, а дерево помещается в состояние ошибки. Проверка ошибок необходима только перед использованием данных.
Приведенный выше пример автоматически выделяет узлы. Вместо этого в средах, ограниченных памятью, может быть предоставлен фиксированный пул узлов. Для максимальной производительности и минимального использования памяти API ожидает для анализа данных о предопределенной схеме.
API записи кодирует структурированные данные в MessagePack.
// encode to memory buffer
char * data ;
size_t size ;
mpack_writer_t writer ;
mpack_writer_init_growable ( & writer , & data , & size );
// write the example on the msgpack homepage
mpack_build_map ( & writer );
mpack_write_cstr ( & writer , "compact" );
mpack_write_bool ( & writer , true);
mpack_write_cstr ( & writer , "schema" );
mpack_write_uint ( & writer , 0 );
mpack_complete_map ( & writer );
// finish writing
if ( mpack_writer_destroy ( & writer ) != mpack_ok ) {
fprintf ( stderr , "An error occurred encoding the data!n" );
return ;
}
// use the data
do_something_with_data ( data , size );
free ( data );В приведенном выше примере мы кодируем в растущий буфер памяти. Вместо этого писатель может написать в предварительно выделяемый или стек-буфер (с предыдущими размерами для типов соединений), избегая необходимости распределения памяти. Автор также может быть предоставлен функцией промывки (например, файл или функция записи сокета) для вызова, когда буфер заполнен или когда написано.
Если возникает какие -либо ошибки, писатель помещается в состояние ошибки. Автор будет помечать ошибку, если будет записано слишком много данных, если неправильное количество элементов записано, если произойдет сбой распределения, если данные не могут быть промываны и т. Д. Никакой дополнительной обработки ошибок в приведенном выше коде; Любые последующие записи игнорируются, когда писатель находится в состоянии ошибки, поэтому вам не нужно проверять каждую запись на предмет ошибок.
Приведенный выше пример использует mpack_build_map() для автоматического определения количества содержащихся пар клавиш. Если вы знаете, что заканчивают количество необходимых элементов, вы можете передать его в mpack_start_map() вместо этого. В этом случае соответствующий mpack_finish_map() в режиме отладки утверждает, что ожидаемое количество элементов было фактически записано, что может не сделать другие библиотеки C/C ++.
MPACK богат функциями, сохраняя при этом очень высокую производительность и небольшую площадь кода. Вот короткая таблица функций, сравнивая его с другими анализаторами C:
| МПК (v1.1) | MSGPACK-C (v3.3.0) | CMP (v19) | CWPACK (v1.3.1) | |
|---|---|---|---|---|
| Нет требований LIBC | ✓ | ✓ | ✓ | |
| Растущий писатель памяти | ✓ | ✓ | ✓* | |
| Файл ввода/вывода | ✓ | ✓ | ✓* | |
| Управление по ошибкам состояния | ✓ | ✓ | ||
| Покрементный анализатор | ✓ | ✓ | ✓ | |
| Дерево -потоковой анализатор | ✓ | ✓ | ||
| Отслеживание размера составного размера | ✓ | |||
| Автоматический размер соединения | ✓ |
Здесь доступна более крупная таблица сравнения функций, которая включает в себя описания различных записей в таблице.
Этот бензольный комплекс сравнивает производительность MPACK с другими реализациями форматов сериализации схем. MPACK превосходит все библиотеки JSON и MessagePack (кроме CWPACK), а в некоторых тестах MPACK в несколько раз быстрее, чем Rapidjson для эквивалентных данных.
Концептуально, MessagePack сохраняет данные аналогично JSON: они оба состоит из простых значений, таких как числа и строки, хранятся иерархически в картах и массивах. Так почему бы просто не использовать JSON? Основная причина заключается в том, что JSON предназначен для того, чтобы быть читаемым человеком, поэтому он не так эффективен, как формат бинарной сериализации:
Типы соединений, такие как строки, карты и массивы, разграничены, поэтому соответствующее хранилище не может быть выделено заранее. Весь объект должен быть проанализирован, чтобы определить его размер.
Строки не хранятся в их родном кодировании. Специальные символы, такие как цитаты и бэк -хлебы, должны быть сбежаны при написании и конвертации обратно при чтении.
Числа особенно неэффективны (особенно при анализе плавания), что делает JSON неуместным в качестве базового формата для структурированных данных, которые содержат много чисел.
Бинарные данные вообще не поддерживаются JSON. Небольшие бинарные капли, такие как иконки и миниатюры, должны быть закодированы или пропущены в основе.
Вышеуказанные проблемы значительно увеличивают сложность декодера. Полнофункциональные декодеры JSON довольно велики, и минимальные декодеры, как правило, оставляют такие функции, как струнный разбор и анализ плавания, вместо этого оставляя их пользователю или платформе. Это может привести к трудностям, специфичным для платформы и локали, а также к большему потенциалу для уязвителей безопасности. Это также значительно снижает производительность, делая JSON непривлекательным для использования в таких приложениях, как мобильные игры.
Хотя неэффективность пространства JSON может быть частично смягчена посредством минификации и сжатия, неэффективность производительности не может. Что еще более важно, если вы министерствуете и сдавляете данные, то зачем использовать читаемый в первую очередь, человеческий формат?
Процесс сборки MPACK не превращает MPACK в библиотеку; Он используется для построения и запуска модульных тестов. Вам не нужно строить MPACK или набор для тестирования модуля для использования MPACK.
См. Test/readme.md для получения информации о том, как тестировать MPACK.
