4

std::stringこんにちは私は、クライアントによって提供されたバッファで動作できる機能を備えた文字列クラス（のような）を実行するという私のアイデアについて一般の人々に投票したいと思いました。

あなたが予見する危険は何ですか？古典的な匂いですか？etcaetera

私はそう意味します：

char ext[64] = {0};
my::string s(ext, my::string::acquire_RW);
size_t len = s.size();
size_t pos = s.find("zboub");
my::string s2(s);   // uses true (alloc+)copy semantic here.

だから私は2つの戦略を予見します：acquire_RWそしてacquire_ROそれは文字の変更を許可するextかどうかです。また、RO非constメソッドのRW場合、およびバッファを拡張する必要があるメソッドの場合。現時点でのみ割り当ててコピーします。

ある意味で、my::stringタイプはタイプのデコレータになりchar*ます。

もちろん、デコレータがクライアントの要件として残される前に、外部バッファを解放しないように注意してください。

あなたの懸念を共有してくれてありがとう

4

2 に答える 2

1

「グッドプラクティス」への答えは難しいです。一般的には良い習慣ではありませんが、特定のユースケースでは非常に良い習慣です。それはすべて、提供されたメモリの存続期間にクライアントをどれだけ信頼できるかに依存します。一般的に：信頼はありません。特別な場合：OK。

パフォーマンスに関して考慮すべき重要なことが1つあります。

割り当てられた文字列のバリアントの暗黙的な共有（コピーオンライトと参照カウントを使用）を使用する予定はありますか？または、値のセマンティクスを使用する予定ですか（常にコピーし、参照しないでください）？

マルチプロセッサおよびマルチスレッド環境では、値のセマンティクスが文字列の推奨される方法です。暗黙的な共有を使用することによるパフォーマンスの向上は、マルチスレッド環境で必要なロックによって破壊されます。

マルチスレッドの場合でも、提案は理にかなっていることに注意してください。外部メモリから割り当てられたバリアントに移動するときにコピーオンライトを完全に使用でき（ロックは不要）、それ以降は値のセマンティクスを使用できます（ロックも不要）。これが最適です。

たとえば、多くの文字列を含むファイルをメモリマップし、これらの小さな文字列とフラグメントメモリのコピーを保存したくないという、非常に特殊なユースケースでバリアントがうまく機能すると思います。

ただし、一般的なケースでは、心配する必要はなく、を使用するだけstd::stringです。

于 2013-03-26T08:24:07.773 に答える
0

それは素晴らしいアイデアだと思いますが、私は読み取り専用に固執します。std::stringもちろん、メモリ割り当てを節約できる状況がない限り、RWには完全に適しています。

ただし、これはかなり最適化されているため、静的文字列が問題を引き起こしていることがわかっていない限り、努力する価値はないかもしれません。

于 2013-03-26T08:08:26.020 に答える