2

東京キャビネット（C言語のオリジナルAPI）を使ったシステムをC++で構築しています。問題は、次のようなクラスを保存したいことです:

    class Entity {
      public:
        string entityName;
        short type;
        vector<another_struct> x;
        vector<another_struct> y
        vector<string> z;
    };

問題は、ベクトルと文字列が可変長であることです。void* (私のオブジェクト) を Tokyo Cabinet に渡して格納できるようにする場合、オブジェクトのサイズもバイト単位で渡す必要があります。しかし、それは簡単にはできません。

オブジェクトのバイト数を決定する最良の方法は何ですか? または、東京キャビネットに可変長オブジェクトを格納する最良の方法は何ですか?

私はすでにシリアル化ライブラリを探すことを検討しています。

ありがとう

4

5 に答える 5

9

非PODC++構造体/クラスを生のバイトシーケンスとして移植可能に扱うことはできません。これは、ポインタまたはstd::stringandの使用に関係ありstd::vectorませんが、後者は実際には壊れることを事実上保証します。最初にオブジェクトを文字のシーケンスにシリアル化する必要があります-優れた、柔軟なクロスプラットフォームのシリアル化フレームワークのためにBoost.Serializationをお勧めします。

于 2009-08-19T21:24:14.983 に答える
4

それよりも悪いと思います。ベクトルの実際のストレージは、オブジェクトの残りの部分と連続していません。s がヒープ上の個別の割り当てにデータを保持していることがわかりstd::vector<>ます (必要に応じてデータを拡張できるようにするため)。C++ と STL を理解する API が必要です。

要するに。これはうまくいきません。

于 2009-08-19T21:14:10.340 に答える
0

はい、ブーストシリアライゼーションまたはプロトブフを使用してオブジェクトを滅菌し、キャビネットに入れることをお勧めします

于 2009-12-18T18:54:54.213 に答える
0

Protocol Buffersを使用して、C++ オブジェクトを Tokyo Cabinet データ値として保存します。

Protocol Buffers では、構造を指定してから、C++、Python、および Java のマーシャリング/アンマーシャリング コードを生成します。あなたの場合、.proto ファイルは次のようになります。

message Entity {
    optional string entityName = 1;
    optional int32 type = 2; //protobuf has no short
    short type = 3;
    repeated AnotherStruct x = 4;
    repeated AnotherStruct y = 5;
    repeated string z = 6;
};

特にデータベースが長期にわたって存在する場合、たとえば新しい分野をカバーするために更新できるシステムは非常に価値があります。XML などとは対照的に、protobuf は非常に高速です。

于 2009-12-31T09:29:51.413 に答える
0

HDF5を使用していますが、同様の問題がありました。私の場合、オブジェクトのサブパーツを読み取ることができるという追加の要件があるため、シリアル化は実際にはオプションではありません。

HDF は、インデックスを使用してデータにアクセスする大きな配列によく似ています。another_struct私が使用する解決策は、型を格納するテーブルに「前のインデックス」を追加することです。

たとえば、「x」と「y」にそれぞれ 3 つと 2 つの要素がある場合、データは次のように格納されます。

[ index ] [ another_struct data here ] [ previous_index ]
[   0   ] [       x data 0           ] [ -1 ]
[   1   ] [       x data 1           ] [  0 ]
[   2   ] [       x data 2           ] [  1 ]
[   3   ] [       y data 0           ] [ -1 ]
[   4   ] [       y data 1           ] [  3 ]

次に、メインのエンティティ テーブルに、最後に追加されたインデックスが格納されます。 

[ index ] [ Entity data here ] [ x ] [  y ]
[   0   ] [        ...       ] [ 2 ] [  4 ]

私は東京キャビネットの仕組みにあまり詳しくないので、このアプローチは機能するはずですが、そのデータ形式には最適ではない可能性があります。理想的には、実際の Tokyo Cabinet オブジェクトへのポインターを保持できる場合は、上記のようにインデックスを使用するのではなく、それらのポインターを格納できます。

于 2009-08-20T09:39:17.457 に答える