Удобное хранение текста в памяти

Очень похоже на Suffix Tree

Похоже на Ropes.

Какая обработка подразумевается?

Обработка в смысле редактирование текста, как в текстовых редакторах?

Или обработка в смысле ведение поиска в этом тексте?

Или что-то совсем другое?

Да, вроде Ropes называлось! :-)

Вообще обработку я хочу делать для текстового редактора, вспомнил про сабж, хочу сейчас почитать разные методы удобной обработки текста :-)

За Suffix tree тоже спасибо, почитаю :-)

Ура! Еще одна победа в состязании телепатов.

Твой кунг-фу лучше!)))

http://en.wikipedia.org/wiki/Gap_buffer

может то Сэджвик был и говорил про всякие Trie?

Вообще обработку я хочу делать для текстового редактора

а какую конкретно обработку?

или ООП головного мозга, GoF и http://en.wikipedia.org/wiki/Flyweight_pattern ?

или ООП головного мозга, GoF и http://en.wikipedia.org/wiki/Flyweight_pattern ?

не, не, не...

A flyweight is an object that minimizes memory use [..]

ТС же обрисовал несколько другую задачу

[..] помимо простого хранения текста в памяти разработан еще один метод (приводилось его название), который позволяет быстро обрабатывать этот самый текст, правда требует больше памяти.

В SXemacs http://www.sxemacs.org/ используются Skip List http://en.wikipedia.org/wiki/Skip_list и Bloom Filter http://en.wikipedia.org/wiki/Bloom_filter

Емакс вообще в этом плане интересен — GNU Emacs критиковали за неудобное представление строк в текстовых буферах, и медлительность вследствие, поэтому XEmacs и SXEmacs сделали всё по-своему.

Вообще вид структуры зависит от требуемой обработки. Стандартные ASCIZ-строки, завершающиеся нулём, приводят к strlen за O(n), и долгому strcat (чуть менее долгому, если делать strcat, возвращающий указатель на конец). Поэтому практически везде изобретают собственный класс строк, хоть паскалевские, хоть ropes, хоть какую-то более удобную структуру. Какую именно — сильно зависит от того, что со строками собираешься делать. http://xahlee.org/emacs/elisp_text_processing_lang.html

По крайней мере, пока TC не раскроет тему, в чём именно заключается обработка, непонятно, что именно посоветовать.

По крайней мере, пока TC не раскроет тему, в чём именно заключается обработка, непонятно, что именно посоветовать.

дык ждём :)

сорри, что не заходил. я думал вопрос исчерпан, хотя можно продолжить тему в сторону ваших советов) Суть задачи в разработки редактора, который может редактировать довольно большие текстовые файлы (для дизассемблированного файла, 10мб+), буфер нужно удобно парсить, выполнять обычные текстовые операции - поиск, замену и проч, подсветку. Проект не горит, я для себя делаю, могу хоть месяц думать, читать статьи, книжки)

пока думаю над таким решением: представлять буфер ввиде заплаток-буферов. - первичный буфер для текстового файла - он не измениется во время редактирования - все последующие буферы хранят добавленный текст по сути это чем-то напоминает GapBuffer, только текст при перемещении курсора не копируется в первичный буфер, а этот буфер добавляется в список. После сохранения получаем новый первичный буфер, без заплаток.

Получаем два слоя, на нижнем - буферы текста, начиная с самого большого первичного, где храниться текст, загруженный из файла и заплатки - все эти буферы могут храниться в списке. Верхний уровень - список, элементы которого указывают на буфер, в котором хранится текст, за который отвечает этот элемент, начало текста в буфере и длину (можно просто указатели начала и конца текста). Это позволяет ссылаться парсеру и анализатору кода на различные участки кода практически не заботясь о том, что объявление переменной было перемещенно на несколько строчек вниз (хотя конечно нужно следить, чтобы не было удалено). Удалить фрагмент текста, значит разбить элемент (на верхнем уровне слоя) на два, пропустив участок буфера, в котором храниться удаленный текст