別の STL コンテナーにロープを使用するのはどのような状況でしょうか?
19485 次
5 に答える
44
ロープはスケーラブルなストリングの実装です。ロープは、ストリング全体を含む効率的な操作のために設計されています。代入、連結、部分文字列などの操作には、文字列の長さとはほとんど関係なく時間がかかります。C 文字列とは異なり、ロープは、編集バッファーやメール メッセージなどの非常に長い文字列の適切な表現です。
利点:
長い文字列を含む連結および部分文字列操作が大幅に高速化されました。10 メガバイトのロープの途中に文字を挿入するには、たとえば編集履歴の一部として元のコピーが保持されている場合でも、数十マイクロ秒のオーダーが必要です。対照的に、これは、従来の「フラットな」文字列表現の場合、1 秒程度かかります。連結に必要な時間は、ほとんどのアプリケーションで一定と見なすことができます。テキスト エディター内のファイルの表現としてロープを使用することは完全に合理的です。
スペースのパフォーマンスが大幅に向上する可能性があります。ロープを少し変更すると、元のロープと記憶を共有できます。ロープは小さなチャンクで割り当てられるため、大きなブロックによって引き起こされるメモリの断片化の問題が大幅に軽減されます
代入は、(おそらく参照カウントされる) ポインターの代入です。参照カウント コピー オン ライトの実装とは異なり、コピーの 1 つが後でわずかに変更されたとしても、これはほぼそのままです。編集履歴などで、古いバージョンの文字列をチェックポイントするのは非常に安価です。
文字を生み出す機能を縄と見ることができる。したがって、ロープの一部は 100MByte ファイルである可能性があり、文字列のそのセクションが検査されたときにのみ読み取られます。このようなファイルの最後に文字列を連結しても、ファイルを読み取る必要はありません。(現在、この機能の実装は不完全です。)
https://wayback.archive.org/web/20130102093702/https://www.sgi.com/tech/stl/Rope.html
于 2010-05-13T11:46:44.080 に答える
8
stringこれは、大きなデータ サイズを処理する非標準の代替手段です。仕組みについてはこちらをご覧ください。
于 2010-05-13T11:46:11.823 に答える
4
ロープの唯一の悪い点は、スレッドと誤用です。
Linux (およびおそらく他のほとんどの OS) では、スレッドセーフ コードがロープを非常に遅くしていると言われています。したがって、組み込みプラットフォームで単一のスレッドを使用しているため、そのコードを切り取るだけです ( threads-offのコンパイラ定義を設定します)。
それ以外の場合、ロープは文字列よりもはるかに高速であり、大きなバッファーでメモリ不足になる可能性が低く、大きなバッファーの編集でははるかに高速です。聖書の途中で悪い文字を削除するなど。
これは、ロープがデータとして解釈される方法によるものです。最終的な文字列を生成するために、リンクされたリストを介してチェーン化された多くの小さな「文字列」として。
于 2011-03-24T01:30:04.543 に答える
2
私はそれをまったく使用しませんが、それは私が「簡単な移植性」のフリークであり、ボグ標準のコンテナーのみを使用する傾向があるためです。ロープは SGI の STL 実装の一部であり、C++ 標準の一部ではありません。
于 2010-05-13T11:48:31.320 に答える
2
ここでは、文字で構成される文字列に重点が置かれていますが、ロープは (シーケンス内の任意の場所で) 高速な挿入と削除を行う単純な 1D シーケンスです。
このような基本的な機能が (文字列以外では) ほとんど必要とされないことは、少し驚くべきことです。整数のロープをどこで使用しますか? それを操作するには、どこかからインデックスを取得する必要があるため、わかりません。
実世界で最も考案された例は、何千もの画像で構成されたデータセットをユーザーが表示できるようにする UI を作成している場合で、ユーザーはそれらの一部を削除し、他の順序を並べ替えることができる必要があります。
于 2016-05-03T23:11:26.010 に答える