1

プロジェクトの 2 つの異なるブランチからのデータをシリアル化しています。データは、 を使用してテキスト アーカイブ形式で出力されますboost::serialization。2 つのシリアル化されたファイル間で差分が作成されるため、出力の違いが発生する可能性があるポイントをよりよく確認できるように、シリアル化された各部分間のシリアル化されたファイルにいくつかのデバッグ メッセージも追加します。

現在使用しているコードの概要は次のとおりです。

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;
}

最初は、使用された演算子 ( &vs <<) が出力に違いを生んだと思っていましたが、違いはありません。次のテキスト ファイルが得られます。

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"

これは予想される動作ですか、それともこの出力を回避する方法はありますか? 他の実際のレコードの場合、他のそのような「制御コード」、マーキング長などの明らかな使用はありません。

デバッグ出力を追加すると便利ですが、前述のデバッグ文字列の長さが異なる可能性があるため (ブランチの 1 つで大量のリファクタリングが発生したため)、差分によって誤検知が発生します。

任意の考えをいただければ幸いです、ありがとう!

4

1 に答える 1

2

私はこれが可能であることを疑います。

ここで直面する問題は、テキスト出力を解析して逆シリアル化する必要があることです。簡単に解析できるようにテキスト出力を構造化するには、主に 2 つの方法があります。

  • 長さがプレフィックスされた文字列
  • 特殊文字 (エスケープコード付き)

たとえば、xml アーカイブでは、タグは and で囲まれて<おり>、これらの文字を自分で使用することはできません。代わりに、エスケープ コード&lt;&gt;それぞれを使用します。一方、Redis 形式を見る13$Hello, World!と、レコードの長さが数字の文字列であり、その後に $ が続き、その後に実際のレコードが続くようなことがわかります。

前者の方法 (長さのプレフィックス文字列) ははるかに効率的ですが、人間が書き込める可能性ははるかに低くなります。

Boost::Serialization のドキュメントから、「人間が読める」アーカイブが 2 つあります。

  • boost::text_[i/o]archive長さがプレフィックスされた文字列を使用します(らしい)
  • boost::xml_[i/o]archivexml 表現を使用します

に切り替えることをお勧めしboost::xml_oarchiveます。

于 2013-02-13T08:01:49.717 に答える