1

私はProtocolBuffersとOpensSSLを使用して生成し、HMACを使用してから、CBCが2つのフィールドを暗号化して、セッションCookie（同様のKerberosトークン）を難読化します。

ProtocolBuffersのAPIはstd::stringsと通信し、バッファキャッシングメカニズムを備えています。同じスレッドでの連続した呼び出しに対して、スレッドローカルメモリに配置することにより、キャッシュメカニズムを利用します。さらに、OpenSSLHMACとEVPCTXも同じスレッドローカルメモリ構造に配置されます（スレッドローカルメモリを使用する理由と、単一スレッドでも可能になる大幅な高速化の詳細については、この質問を参照してください）。

これらのCookie文字列の生成と逆シリアル化「myalgorithms」は中間void *のsとstd::stringsを使用し、Protocol Buffersには内部メモリ保持メカニズムがあるため、「myalgorithms」にこれらの特性が必要です。

では、一般的なスクラッチメモリを実装するにはどうすればよいですか？std :: stringオブジェクトのrdbuf（streambuf --strinbuf ??）についてはよくわかりません。おそらく、「私のアルゴリズム」の実行中にこれまでに遭遇した最小の一般的なサイズにそれを拡大する必要があるでしょう。考え？

私の質問は次のようになります。「文字列の内部バッファは再利用可能ですか。再利用できる場合は、どのように使用しますか？」

編集（新しい質問）：

Vladの投稿後、std::stringとvoid*cスタイルのスクラッチバッファが必要であることが反映されているようです。私の質問は次のようになります：人気のあるstlの文字列実装は、メモリを必要としないときにメモリを保持しますか？（私のニーズはおそらく128バイトから10KBの間にとどまるでしょう）。

4

1 に答える 1

2

独自にデータの割り当てと再割り当てを行うため、コンテンツ全体std::stringがTLSに存在することを期待するべきではありません。std::string簡単なアイデアは、ヒープに構造体を割り当て、その構造体へのポインターをTLSに格納することです。

編集：
AFAIKrdbufはストリームの機能であり、の機能ではありませんstring（こことここを参照）。

編集：文字列の代わりに
使用することをお勧めします。連続している必要があります。繰り返しになりますが、TLSへのポインタだけを配置する方がおそらく良いでしょう。同じ記事へのコメントによると、標準ではcharから始めて連続している必要があります。std::vectorvectorstring&(str[0])

于 2010-04-20T12:52:28.513 に答える