一般的に、C++ でバイナリ データを格納する最良の方法は何ですか? 私が知る限り、オプションは文字列または vector<char> を使用することに要約されます。(特に C++ について言及しているので、char* と malloc() の可能性は省略します)。
通常は文字列を使用するだけですが、見落としているオーバーヘッドがあるかどうか、または STL が内部で行う変換がバイナリ データの健全性を台無しにする可能性があるかどうかはわかりません。誰かがこれについての指針（har）を持っていますか？何らかの提案や好みはありますか？
メモリが連続しているため、char の vector は便利です。したがって、berkley ソケットやファイル API などの多くの C API で使用できます。たとえば、次のことができます。
std::vector<char> vect;
...
send(sock, &vect[0], vect.size());
そしてそれはうまくいくでしょう。
基本的に、他の動的に割り当てられた char バッファーと同じように扱うことができます。上下にスキャンして、マジック ナンバーやパターンを探すことができます。部分的にその場で解析できます。ソケットから受信する場合、非常に簡単にサイズを変更して、より多くのデータを追加できます。
欠点は、サイズ変更が非常に効率的ではないこと (慎重にサイズ変更または事前割り当てを行うこと) であり、配列の先頭からの削除も非常に非効率的です。たとえば、データ構造の先頭から一度に 1 つか 2 つの文字だけを非常に頻繁にポップする必要がある場合は、この処理の前に両端キューにコピーすることをお勧めします。これにはコピーのコストがかかり、メモリーのデキューは連続していないため、C API へのポインターを渡すことはできません。
要するに、飛び込む前にデータ構造とそのトレードオフについて学んでください。
std::string の最大の問題は、現在の標準では、基になるストレージが連続していることを保証していないことです。ただし、文字列が連続していない既知の STL 実装はないため、実際にはおそらく失敗しません。実際、新しい C++0x 標準では、std::string が std::vector などの連続したバッファーを使用することを義務付けることで、この問題を修正しようとしています。
string に対するもう 1 つの反論は、その名前がバイナリ バッファではなく文字列を含んでいることを示唆しているため、コードを読む人を混乱させる可能性があるということです。
とはいえ、ベクターもお勧めです。
私もこれに使用std::stringしていますが、これで問題が発生したことはありません。
1 つの「ポインタ」。これは、昨日コードの一部ではっきりと思い出させてくれました。バイナリ データのブロックから文字列を作成するときは、std::string(startIter, endIter)フォームではなくコンストラクタ フォームを使用しstd::string(ptr, offset, length)てください。 C スタイルの文字列に変換し、最初の 0 文字以降はすべて無視します (文字lengthではなく、指定された「まで」コピーしますlength)。
確かに char のコンテナーを使用する必要がありますが、使用するコンテナーはアプリケーションによって異なります。
Char には、バイナリ データを保持するのに役立ついくつかのプロパティがあります。標準では、char データ型の「パディング」は許可されていません。これは、バイナリ レイアウトでゴミが発生しないことを意味するため、重要です。また、各 char は正確に 1 バイトであることが保証されているため、幅が設定された唯一のプレーン オールド データ型 (POD) になります (他のすべては上限および/または下限によって指定されます)。
文字を格納するための適切な stl コンテナに関する議論は、上記の Doug によって適切に処理されています。どちらが必要かは、ユースケースによって完全に異なります。特別なルックアップ、追加/削除、またはスプライスの必要なしに、繰り返し処理するデータのブロックを保持している場合は、多くのライブラリと関数が想定する std::string よりも意図を明確にする vector をお勧めします。 null で終わる C スタイルの文字列を保持します。