私はパフォーマンスの文脈で尋ねています。stringstream は単なる文字列/ベクトルなので、それに書き込むと、コンテンツ全体がより大きなメモリのチャンクにコピーされる可能性がありますか、それともよりトリッキーな方法 (たとえば、文字列のリストなど) で行われますか?
2 に答える
27.7.3/1 はbasic_ostringstream
、basic_stringbuf
. 27.7.1.3/8 はbasic_stringbuf
、バッファーを再割り当てすることでスペースを確保し、指数関数的な成長を保証するものではないと言っていると思います (したがって、O(1) を償却して追加します)。
しかし、標準のストリーム セクションはかなり不可解であり、常に "as-if" ルールが存在します。deque
そのため、 Underground の使用 (および、誰かが文字列 / バッファを要求したときに統合すること) が実際に禁止されているとは約束できません。
stringstream (またはその点については任意のライブラリ機能) を実装する方法は、標準ライブラリ ベンダー次第です。コンパイラに同梱されている sstream ヘッダーを見て、そこでどのように実装されているかを確認できます。理論上はそこまで…
実際の経験と測定値が示す限り、ostringstream は、データを文字列としてフォーマットするための他の方法と比較して遅いことがよくあります。しかし、繰り返しますが、最適化したいものが実際にパフォーマンスのボトルネックであることを測定した後にのみ最適化してください。そうしないと、せいぜい時間の無駄になります。
ostringstream のパフォーマンスが実際に問題であることが測定で示されている場合は、 Boost.Karma の使用を検討してください。もちろん、Boost.Karma を使用する理由はパフォーマンスだけではありません。そのため、文字列ストリームを使用して既存のコードを変更するのではなく、新しいコードを開始する場合は、最初から Karma を使用することをお勧めします。