Повысить сериализацию — избежать вывода длины строки?

Я сериализую некоторые данные, поступающие из двух разных веток проекта. Данные выводятся в виде текстового архива с использованием boost::serialization, Поскольку между двумя сериализованными файлами необходимо сделать различие, я также добавляю несколько сообщений отладки в сериализованные файлы между каждой сериализованной деталью, чтобы лучше видеть точку, в которой может возникнуть разница в выходных данных.

Вот широкий обзор кода, который я сейчас использую:

std::ofstream ofs("./SomeFile.txt"); // for brevity's sake, no actual path used
{
boost::archive::text_oarchive oa(ofs);
std::string debug_str;

debug_str = "\n\nPart 1\n";
oa & debug_str;

// ... some other serialized parts ...

debug_str = "\n\nPart 145\n";
oa << debug_str;
}

Вы можете заметить, что я сначала подумал, что используется оператор (& против <<) сделал разницу в выводе, но это не так, я получаю следующий текстовый файл:

22 serialization::archive 7 9 [CRLF]
[CRLF]
Part 1 [CRLF]
11 [CRLF]
[CRLF]
Part 145 [CRLF]

22 serialization::archive 7 часть — это стандартный заголовок сериализации Boost, определяющий тип архива, который я предполагаю. Потом приходит часть, которую я хотел бы удалить, а именно 9 — после небольшой погони за гусем я понял, что 9 это длина "\n\nPart1\n" строка!

Это ожидаемое поведение или есть способ обойти этот результат? В случае других фактических записей нет очевидного использования других таких «контрольных кодов», длины маркировки или чего-либо подобного.

Было бы полезно добавить некоторые выходные данные отладки, но поскольку длины упомянутых строк отладки могут различаться (так как в одной из ветвей произошел интенсивный рефакторинг), diff дает некоторые ложные срабатывания.

Любые мысли будут оценены, спасибо!

1

Решение

Я сомневаюсь, что это возможно.

Проблема, с которой вы здесь сталкиваетесь, заключается в том, что текстовый вывод должен быть разобрал обратно быть десериализованным. Существует два основных способа структурирования текстового вывода, чтобы его можно было легко проанализировать:

  • строки с префиксом длины
  • специальные символы (с escape-кодами)

Например, в XML-архиве теги окружены < а также > и вы не можете использовать эти символы самостоятельно, вместо этого используйте экранированные коды &lt; а также &gt; соответственно. С другой стороны, если вы посмотрите на формат Redis, вы увидите такие вещи, как 13$Hello, World! где длина записи представляет собой строку цифр, за которой следует $, за которым следует фактическая запись.

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

Из документации Boost :: Serialization я вижу два разных «читаемых человеком» архива:

  • boost::text_[i/o]archive использует строку с префиксом длины (кажется)
  • boost::xml_[i/o]archive использует представление XML

Вы можете переключиться на boost::xml_oarchive,

2

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

Других решений пока нет …

По вопросам рекламы ammmcru@yandex.ru
Adblock
detector