問題タブ [boost-serialization]

Windows と Linux の両方でデータを (逆) シリアル化する必要があります (そしてその間でファイルを転送します)。例にある Boost のシリアライゼーションライブラリのポータブル バイナリ アーカイブを使用したかったのです。/

これは Windows (VS 2008) では問題なく動作しますが、GCC 4.3.2 ではコンパイルに失敗し、次のエラーが発生します。

誰でも解決策を提案できますか?

どうもありがとう！

ブースト message_queue とシリアライゼーションを一緒に使用する小さな実例を誰でも共有できますか? クラスを使用してプロセス間でデータを交換したいのですが、研究に行き詰まっています。

C++ で、基本クラスへのポインターを持っているときに派生クラスの関数を呼び出すときに問題が発生しています。

編集：いくつかの回答はCRTPに私を紹介しました

しかし、私のポイントは、現在処理されているタイプを認識していないため、「Base *」ではなく「Base *」クラスへのポインターが必要であるということです (現在のインスタンスは、ある種のファクトリから作成されます)。

クラス：

使用法：

言語が仮想テンプレート機能をサポートしていないため、func を仮想化できません。

クラスのみがテンプレート引数を持つ場合にのみ許可され、その中の関数にテンプレート引数がある場合は許可されません。

Boost.Serialization 内で解決された同様の問題を見たことがありますが、解決策を理解できませんでした。

ありがとう、

コビー・メイア

私はアプリでかなり複雑なデータ構造（主にSTLコンテナーを使用）を使用し、Boost（v1.34）を使用してそれらをシリアル化します。

デバッグシンボル（gcc -g）を使用してコンパイルするたびに、結果の実行可能ファイルは巨大になります（約25 MB）。すべてのデバッグシンボルを削除すると、サイズが最大3MBに減少します。

サイズが大きくなった原因を突き止めてみましたが、シリアル化の方法が原因のようです。特に、シリアル化を呼び出すモジュールのオブジェクトファイル（「oarchive << myObject」などのコード）は大きく、シリアル化部分をコメントアウトするとサイズが大幅に小さくなります。

これらのシンボルの生成を防止すること、またはそれらを選択的に取り除くことは可能ですか？
自分のコードのデバッグシンボルが必要なため、すべてのシンボルを削除することはできません。

さて、最近ブーストに切り替えて、単純なオブジェクトまたは単純なクラスのシリアル化を部分的に理解しています（ブーストチュートリアルは私を混乱させます）が、クラスメンバーを含む3D配列をシリアル化するにはどうすればよいですか？

TileListという配列（std :: vector）があります。これには、クラスTileのオブジェクトが含まれ、クラスTileにはintTileIDとintTilePassabilityの2つの変数しか含まれていません。

シリアル化のチュートリアルが目立たない方法とSTLコンテナの方法で行うように試してみましたが、エラーのスタックが返されます。誰かがそれを正しく行う方法を説明できますか？ありがとうございました。

これは私の問題を表すサンプルです。finalTimeが25を超えない限り、マップは完全に正常にシリアル化されます。ブーストユニットテストで、std::exception入力ストリームエラーが発生しました。また、このコードはpolymorphic_text_archivesを使用して正常に機能します。マップの読み取り中にエラーが発生します。

Boostシリアル化ライブラリを使用してクラスを文字列にシリアル化しようとしていますが、クラスにはいくつかのdoubleメンバー変数が含まれています。

以下は、シリアル化に使用しているコードです。

これが私のPointクラス内のシリアル化メソッドです。

文字列にシリアル化すると、ブーストは期待どおりに二重から文字列への変換を処理しないようです（丸めの問題があるようです）。少し調べてみると、他の人が同じ振る舞いを報告しているようです。また、doubleを文字列に、またはその逆に変換することに関連する精度に関連する問題と、これが問題を引き起こす可能性があることも理解しています。

奇妙なことに、私にはわかりませんが、stringstream自体を使用してdoubleをストリームにリダイレクトしたり、boostのlexical_cast関数を使用してstringstream.str（）から変換したりすると、これは発生しないようです。ダブルに。boostが独自のシリアル化/逆シリアル化クラスを持っていることを発見する前に、私は実際にstringstreamおよびlexical_cast呼び出しを使用して独自のクラスを作成しましたが、問題なく機能しました。シリアル化ライブラリを放棄して、以前の状態に戻る必要がないことを本当に望んでいます。うまくいけば、いくつかの設定/特性などがあります。私は行方不明です。

やあ...質問をもっとよく説明しようとしています...TCP接続を介してデータを送信する前にブーストシリアル化テキストアーカイブを使用しています...受信したデータをJavaアプリケーションに渡す必要があります...シリアル化されたストリームは、データのみ、またはデータ+ブーストシリアル化（タグ、コードなど）で構成されます...この場合、データをjavaアプリケーションに転送する唯一のチャンスは、転送する前にそれらをフィルタリングすることです。 ..

私の質問は、 5年前のこのスレッドで説明したものと同じです（これには良い答えはありません）。

次のように、オブジェクトをバイトバッファにシリアル化します。

これをループで実行すると、パフォーマンスがかなり悪くなります。1秒あたり最大14,000個のオブジェクトを取得します。

私はbinary_oarchiveの再現に至るまで問題を特定しました。ループ内の同じアーカイブインスタンスで同じ文字列に書き込むと、最大220,000オブジェクト/秒が得られますが、オブジェクトは次々にシリアル化されます。これは私が望むものではありません。クリアしたい各オブジェクトがシリアル化された後、同じバッファーを再利用します（最初までシークします）。

どうやってやるの？

XMLファイルにBoost::Serializationを使用するように既存のMFCC++アプリケーションを移植しています。私のCDocumentオブジェクトには、アプリのすべてのデータが含まれています。私はシリアル化機能を次のように実装しました：

保存イベントと読み込みイベントをキャプチャするために、CDoc * .cppファイルで、基本クラス関数OnOpenDocument（）とOnSaveDocument（）をオーバーロードして、Boost::Serializationを実装しました。

ドキュメントの保存は正常に機能します。問題は、ドキュメントのロードが機能しないことです。ポインタが別のアドレスに戻るため、BoostライブラリはCMyDocオブジェクトをコピーしているようです。これは、ロードされたファイルが現在のドキュメントにロードされていないことを意味します。CDocはブーストで自分自身を上書きできますか？MFCCArchiveで可能です。

この行を「POSSIBLEsolution」と表示することを考えましたが、これはCMyDocクラスのコピーコンストラクターを実装することを意味します。これにより、変数ごとに2行のコードがあるという点でブーストの利点の1つが削除されます。1。ar＆BOOST_SERIALIZATION_NVP（m_Param1）//pDocに保存およびロードする2.this-> m_Param1 = pDoc.m_Param1 // in CMyDocコピーコンストラクタ

CMyViewをオーバーロードしてファイルを開いてイベントを保存すると、Doc/Viewアーキテクチャによって提供されるMRUリスト管理が実行されません。

これは何百万回も行われたと確信していますが、オンラインで情報を見つけることができません。変！どんな助けでも大歓迎です：D

ドキュメントを詳しく読むと、Boostは、シリアル化されたポインターが新しいキーワードで逆シリアル化されていることを認識していることがわかります。「ポインターのシリアル化は、次のようなコードでライブラリに実装されています。」

ドキュメントでは、必要に応じてこの関数をオーバーロードすることを推奨しています。

ただし、これもCMyDocコピーコンストラクターを実装する必要があります。Aaarrgghhhh !!

それが誰かを助ける場合に備えて、私はこれについてロバート・ラミーから返事をもらいました。基本的に、私は明らかな何かを見逃していませんでした。CMyDocserialize（Archive＆ar、const unsigned int version）関数はランナーではなかったので、別々のboost_save関数とboost_load関数を実装しました。OnOpenDocumentとOnSaveDocumentをオーバーロードする必要がありました。次に例を示します。

BOOL CMyDoc :: OnOpenDocument（LPCTSTR lpszPathName）{clear（）;

}

これが必要なのは、MFC CArchiveがMFCシリアル化機能が終了するまでファイルを所有し、boost::serializationがファイルにアクセスできないようにするためです。CDocument基本クラスは、基本クラスのSerialize関数に戻るときにarが存在すると想定しているため、Serialize関数でar.Abort（）を呼び出しても機能しません。