非常によく似た質問があります
glibcの文字列実装を使用してスタックにstd::stringを割り当てるにはどうすればよいですか?
しかし、もう一度尋ねる価値があると思います。
std::stringフリーストアにオーバーフローするローカルストレージを備えたものが必要です。std::basic_stringはテンプレートパラメータとしてアロケータを提供するので、ローカルストレージを使用してアロケータを作成し、それを使用して次のようにパラメータを設定する必要がbasic_stringあるようです。
std::basic_string<
char,
std::char_traits<char>,
inline_allocator<char, 10>
>
x("test");
inline_allocator期待どおりに機能するクラスを作成しようとしました。ストレージ用に10バイトを予約し、10バイトをbasic_string超える必要がある場合は、を呼び出します::operator new()。動作させることができませんでした。上記のコード行を実行する過程で、私のGCC4.5標準文字列ライブラリはコピーコンストラクターをinline_allocator4回呼び出します。のコピーコンストラクターを作成するための賢明な方法があるかどうかは私にはわかりませんinline_allocator。
他のStackOverflowスレッドで、EricMelskiはChromiumのクラスへのこのリンクを提供しました。
http://src.chromium.org/svn/trunk/src/base/stack_container.h
これは興味深いですが、のドロップイン置換ではありません。これは、をコンテナstd::stringにラップするstd::basic_stringため、オーバーロードを呼び出して。operator->()に到達する必要があるためstd::basic_stringです。
この問題に対する他の解決策は見つかりません。良い解決策がないということでしょうか?そしてそれが本当なら、そしてstd::basic_string概念はstd::allocatorひどく欠陥がありますか?std::basic_stringつまり、これはとの非常に基本的で単純なユースケースである必要があるようstd::allocatorです。コンセプトstd::allocatorは主にプール向けに設計されていると思いますが、これもカバーする必要があると思います。
inline_allocator文字列ライブラリがbasic_stringコピーコンストラクタの代わりにアロケータの移動コンストラクタを使用するように書き直された場合、C++0xの右辺値参照の移動セマンティクスによって書き込みが可能になるようです。誰かがその結果の見通しが何であるか知っていますか?
私のアプリケーションは1秒あたり100万個の小さなASCII文字列を作成する必要があるため、に基づいて独自の固定長文字列クラスを作成するBoost.Arrayことになりました。これは正常に機能しますが、それでも気になります。