私は組み込みアプリを書いています。いくつかの場所では、std::ostringstream を頻繁に使用しています。これは、私の目的には非常に便利だからです。ただし、ストリームにデータを追加すると、malloc と free の呼び出しが多くなるため、パフォーマンスの低下が極端であることがわかりました。それを回避する方法はありますか？
私が最初に考えたのは、ostringstream を静的にして、ostringstream::set("") を使用してリセットすることでした。ただし、関数を再入可能にする必要があるため、これは実行できません。
ストリームを作成する前にデータの大きさがわかっている場合は、コンストラクターがパラメーターとしてバッファーを取ることができる ostrstream を使用できます。したがって、データのメモリ管理はありません。
おそらく、これに対処する承認された方法は、独自のbasic_stringbufオブジェクトを作成して で使用することostringstreamです。そのためには、いくつかの選択肢があります。1 つは、固定サイズのバッファーを使用することで、overflow長すぎる出力を作成しようとすると失敗します。もう 1 つの可能性は、ベクターをバッファーとして使用することです。std::string とは異なり、vector は追加データが一定の複雑さを償却することを保証します。また、強制しない限りバッファからデータを解放することはないため、通常は処理している最大サイズまで大きくなります。その時点から、現在使用可能な長さを超える文字列を作成しない限り、メモリを割り当てたり解放したりしないでください。
まあ、Boogerの解決策は に切り替えることsprintf()です。安全ではなく、エラーが発生しやすいですが、多くの場合、高速です。
いつもではありませんが。両方ともメモリの割り当てと割り当て解除を実行するため、初期化後に私のリアルタイム ジョブでそれ (または ostringstream) を使用することはできません。
この問題を回避する方法は、起動時にすべての文字列変換を実行することを確認するために、多くのフープをジャンプすることです (まだリアルタイムである必要はありません)。独自のコンバーターを固定サイズのスタック割り当て配列に記述した状況が 1 つあったと思います。問題の特定のコンバージョンに期待できるサイズには、いくつかの制約があります。
より一般的な解決策として、固定サイズのバッファーを使用する独自のバージョンの ostringstream を作成することを検討できます (もちろん、境界内でのエラー チェックは保持されます)。少し手間がかかりますが、これらのストリーム操作がたくさんある場合は、それだけの価値があるかもしれません。
std::ostringsteam便利なインターフェースです。カスタム を提供することにより、std::stringをにリンクします。独自の std::streambuf を実装できます。これにより、メモリ管理全体を行うことができます。の適切な書式設定を引き続き取得できますが、メモリ管理を完全に制御できます。もちろん、その結果、フォーマットされた出力は- で得られますが、組み込み開発者であれば、おそらく大きな問題にはなりません。std::ostreamstd::streambufstd::ostreamchar[]
