2

マインド マッピング アプリケーションを作成していますが、「メモ」エディターに最適なデータ構造は何かを考えていました。メモはほんの数個の記号である場合もあれば、ページの長さである場合もあり、更新、編集、シャッフルなどを行っています。アプリはモバイル プラットフォームで実行することを目的としているため、処理とメモリのオーバーヘッドは最小限に抑える必要があります。

私の基本的なアイデアは、編集中にメモを断片化するロープ/リンクリストタイプの構造を実装して、コンテナーがいっぱいになった場合にメモを再割り当てすることによるオーバーヘッドを回避し、動的に成長するベクトルなどで不要なスペースを割り当てないようにすることです。

ただし、メモを断片化しすぎると、必然的にそれ自体でオーバーヘッドが発生します。そのため、実装の 2 番目の部分では、メモの編集中に使用されるロープ構造を、保存と高速読み取りのために順次データ構造に変換することを計画しています。

したがって、基本的にオブジェクトは順次データ構造に格納されて読み取られますが、編集されると断片化されたデータ構造にコピーされ、編集が完了するとオブジェクトは元に戻されます。

これは良いアイデアですか？そうでない場合は、推奨事項を歓迎します。いずれにせよ、私が学ぶことができるいくつかの同様のオープンソース実装を知っている人はいますか?

4

2 に答える 2

3

オープン ソースに関しては、常に emacs があります:-)。しかし、もう少しシンプルなものを探しているのではないかと思います。

ここに唯一の正解はありません。私が見た従来の実装ではstd::vector<char>、カーソルの前のテキスト、空き領域、およびカーソルの後のテキストの 3 つの論理ブロックに分割された 1 つの非常に大きなバッファー (今日) を使用します。このソリューションでは、カーソルを移動するとカーソルが移動するテキストがシフトされますが、カーソルでのテキストの挿入と削除にはシフトが含まれません。

今日、従来のアプローチが正当化されるかどうかはわかりません (組み込みマシンではそうかもしれませんが)。私は std::vector<char>非常に素朴な方法で使用することから始め、典型的な編集セッションからプロファイリング データを取得してから、これを変更するだけでした。Bufferただし、別の戦略への将来の移行を簡素化するために、必要なインターフェイスだけを提供するクラスでラップします。

于 2011-10-26T12:43:18.830 に答える
0

実際に編集する予定のテキストの量によって異なります。以前の回答はstd::vector<char>、どれが限界まで機能するかを示唆していました。

あなたは提案を求めました: 私はScintillaから、特にWiki エディターを実装する際の関連セクションについて多くのことを学びました。

于 2011-10-26T13:27:31.850 に答える