タグ

Learningとbufferに関するshigiryouのブックマーク (5)

  • エディタの基本概念

  • テキストエディタを作るメモ

    初出:2001/12/12 最終更新:2005/07/25 私がGreenPadを作ろうとしたときに 調べてまわって作ったリンク集です。OSやToolkit提供のコンポーネントを 使うのではなく、「独自のテキスト編集コンポーネントを一から作る」場合に 参考となるものを集めました。Windows系に偏っている感が無きにしもあらず。 ソースコードの公開されているエディタやコンポーネント C GNU Emacs (色々な環境) JED (Unix,VMS,MSDOS,OS/2,BeOS,QNX,Win) Meadow (Win) nedit (Win) ne (Unix) Ng (AMIGA,Human68k,MSDOS,Unix) TextMaid (Win/GTK+) tolstoj (Win) vim (色々な環境) C++ Alpha (Win) GreenPad (Win) kajer

  • 各種テキストエディタのデータ構造と処理を邪推する - satosystemsの日記

    鈴川エディタというテキストエディタをご存知でしょうか。 私はついさっき*1知りました。 触れ込みは以下の通り。 小さいメモリ(50MB以下)で大規模テキストファイル(300GB、2,000億行)を編集できる世界唯一の超巨大テキストエディター http://www.szkwjp.com/index.html 興味深いのは他のエディタとの比較。 この比較文を元に、それぞれのエディタのデータ構造を想像して楽しんでみます。 比較文が 2008 年と結構古いので、現在のバージョンとは異なる可能性があります。参考程度ということで。 鈴川エディタ なぜ、50MB 以下のメモリで 300GB のテキストファイルが読み込めるのか。その種明かしは、オリジナルのファイルを 2MB 程度の作業用ファイルに分割し、それらを操作しているためだと思われます。 これなら 300GB のファイルを開く際に、最初の 2MB

    各種テキストエディタのデータ構造と処理を邪推する - satosystemsの日記
  • テキストエディタ用バッファの各種データ構造とその評価 (2)

    vector類をvector類で管理する組み合わせについて、考察とパフォーマンス測定を行う。 測定項目は以下の項目とする。 バッファ構築時間 シーケンシャルアクセス+1文字削除時間・使用メモリ量 シーケンシャルアクセス+1文字挿入時間・使用メモリ量 vector<shared_ptr<array<char>>> 最も基的な組み合わせ。 STL には array が無いので、reserve であらかじめ領域を確保しサイズを固定にした vector<char> を代わりに用いる。 array のサイズは 32KB としてみる。array サイズを変えた場合の計測は余裕があれば行う。 文字データが array サイズ以上になった場合、可能なら前後の array に送る。そうでない場合は新たに array を作成する。 編集コストおよびブロック分割時コストは、ブロックサイズを B とすれば O(

  • テキストエディタ用バッファの各種データ構造とその評価

    概要 テキストエディタのためのバッファの各種データ構造について述べ、 それらを筆者がC++で STLに準じたインタフェースを持つテンプレートクラスとして実装したものについて、 パフォーマンス(処理速度、使用メモリ量)計測を行った結果を報告する。 筆者が実際にテキストエディタを実装する場合にどのデータ構造がよいか、という視点で評価を行う。 目次: はじめに バッファに要求される機能・性能 バッファクラスのインタフェース パフォーマンス計測 各種データ構造 gap_vector<wchar_t> VS. list<wstring> gap_vector<wstring> 終わりに 参考文献 はじめに テキストエディタは、簡単に言うと、シーケンシャルなテキスト情報を保持し、ユーザの指示により内容を表示、修正するプログラムである。 上図のような構造はオブジェクト指向な設計と親和性が高い。 テキスト

  • 1