Я сериализую некоторые данные, поступающие из двух разных веток проекта. Данные выводятся в виде текстового архива с использованием 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 дает некоторые ложные срабатывания.
Любые мысли будут оценены, спасибо!
Я сомневаюсь, что это возможно.
Проблема, с которой вы здесь сталкиваетесь, заключается в том, что текстовый вывод должен быть разобрал обратно быть десериализованным. Существует два основных способа структурирования текстового вывода, чтобы его можно было легко проанализировать:
Например, в XML-архиве теги окружены <
а также >
и вы не можете использовать эти символы самостоятельно, вместо этого используйте экранированные коды <
а также >
соответственно. С другой стороны, если вы посмотрите на формат Redis, вы увидите такие вещи, как 13$Hello, World!
где длина записи представляет собой строку цифр, за которой следует $, за которым следует фактическая запись.
Первый способ (строки с префиксом длины) гораздо более эффективен, но гораздо менее удобен для записи.
Из документации Boost :: Serialization я вижу два разных «читаемых человеком» архива:
boost::text_[i/o]archive
использует строку с префиксом длины (кажется)boost::xml_[i/o]archive
использует представление XMLВы можете переключиться на boost::xml_oarchive
,
Других решений пока нет …