5

私は2つのコンポーネントを持つ分散アプリケーションに取り組んでいます。1つは標準のC++（マネージC ++ではなくLinuxプラットフォームで実行）で記述されており、もう1つはC＃で記述されています。どちらもメッセージバスを介して通信しています。

オブジェクトをC++からC＃アプリケーションに渡す必要がある状況があります。このために、これらのオブジェクトをC ++でシリアル化し、C＃で逆シリアル化する必要があります（.NETでのマーシャリング/アンマーシャリングなど）。このシリアル化は、XMLではなくバイナリで実行する必要があります（パフォーマンス上の理由から）。

Boost.Serialization両端がC++で実装されていたときにこれを行っていましたが、一方の端に.NETアプリケーションがBoost.Serializationあるので、実行可能なソリューションではありません。

C ++と.NETの境界を越えて（逆）シリアル化を実行できるソリューション、つまりクロスプラットフォームのバイナリシリアル化を探しています。

（逆）シリアル化コードをC ++ dllに実装P/Invokeし、.NETアプリケーションで使用できることはわかっていますが、最後の手段としてそれを維持したいと思います。

また、gzipのような標準を使用しているかどうかを知りたいのですが、それは効率的ですか？gzipに代わるものは他にありますか？それらの長所/短所は何ですか？

ありがとう

4

3 に答える 3

5

Google独自のシリアル化ライブラリであるProtocolBuffersをお勧めします。.Net、C ++、およびJavaシリアライザーの両方があります。ほとんどの実装も非常に高速です。

http://code.google.com/p/protobuf/

于 2011-01-13T07:22:49.590 に答える
4

gzipはシリアル化を直接支援しません-ストリームを縮小するだけです（試みます）。これは、ストリーム内の重複データの量に応じて、役立つ場合とそうでない場合があります。テキストが少ない高密度データの場合、gzipによってペイロードのサイズが大きくなるのを見てきました。

個人的にはここでプロトコルバッファを調べます（ただし、私は多くの拡張機能の作成者の1人であるため、偏見があります）。通常（常にではありませんが）基本言語（.protoファイル）でメッセージを定義し、言語固有のツールを実行してクラスを生成します。パフォーマンスは非常に優れています。.NETに焦点を当てると、組み込みのシリアライザー（1 2 3）をはるかに超える可能性があります。

于 2011-01-13T07:26:43.913 に答える
3

もう1つの可能性は、Thriftです。これにはさらに多くのバックエンドがあり、必要に応じて、スケールアウトする場合に備えて、ネットワーク通信に必要なコードの大部分を提供します。

簡単なオブジェクトのシリアル化だけが必要な場合は、json.orgを参照してください。C++/.NETの実装はたくさんあります。

于 2011-01-13T09:51:07.053 に答える