Как организовать память для текстового редактора?

[esl]

ну сосбтвенно в работе это уже лет как 25+ можно посмотреть в МикроМире

[Advertiser]

[psb]

логи парсить надо не редакторм а скриптом на ruby/perl/python

ага, ага, особенно когда не знаешь что искать в них и искать надо всё. почему не хватит просмотрщика? потому что поиском и заменой лог можно чистить находу, адаптивно (что не сможет ни один скрипт).

[Sergey]

В порядке обсуждения, чисто теоретическая идея. Показываю на интуитивнопонятном примере:

Строка до правки:
"Моя Родина - Союз Советских Республик!"

Строка после правки:
"Моя Родина - Союз Советских Социалистических Республик!"

Как должно выглядеть:

Состояние памяти до правки:
адрес_1: "Моя Родина - Союз Советск"
адрес_2: "их "
адрес_3: "Республик!"
адрес_4:

Состояние памяти после правки:
адрес_1: "Моя Родина - Союз Советск"
адрес_2: [управляющий код][адрес4]
адрес_3: "Республик!"
адрес_4: "их Социалистических "[управляющий код][адрес_3]

(управляющий код и адрес занимают 3 байта)

Плюсы:

Не нужно двигать текст вообще.

Минусы:

Вероятно, усложняется и замедляется процедура вывода текста на экран.
Перед сохранением текста необходима дополнительная обработка.

[jerri]

Sergey, Хорошая годная трава.
только зачем?

[bigral]

Не нужно двигать текст вообще.

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

[esl]

ага, ага, особенно когда не знаешь что искать в них и искать надо всё. почему не хватит просмотрщика? потому что поиском и заменой лог можно чистить находу, адаптивно (что не сможет ни один скрипт).

ага, на практике даже во много итераций но скриптом анализировать проще
просто у скрипта сильо больше возможностей править логи

и мало того, скрипт можно будет и завтра использовать ....

опять же, это для меня, и я достаточно давно в эти игры играю

мне проще написать скрипт в пару строк чем в редакторе править руками
да и поиск/замена в редакторах (даже так реализована как в с Sublime text 2) - бледное подобие возможностей скрипта

[Barmaley_m]

просто у скрипта сильо больше возможностей править логи

Это оффтопик, но раз уж сам модератор его поддерживает, то я не могу не ответить. Иногда баги в софте, который пишет лог, таковы, что правила правки лога сложно формализовать в виде скрипта. Может получиться так, что скрипт превратится в парсер лога с конкретными нарушениями структуры с последующей генерацией исправленного лога. Огромный объем кода. Также появляется необходимость отладки скрипта и его проверки, что он не портит лог где-то, где этого совсем не ждешь. Ладно если баг в скрипте приведет к синтаксической ошибке в логе, что парсер лога впоследствии выругается. А если произойдет незаметная порча данных? В моей практике, когда объем правок невелик, а формализация затруднена, как правило было удобнее редактировать логи вручную.

и мало того, скрипт можно будет и завтра использовать ....

Сам по себе такой скрипт, как правило, не подлежит повторному использованию, т.к. баг в программе, записавшей лог, фиксится, так что таких же ошибок в следующих логах уже не будет. Только опыт, полученный при написании и наладке скрипта, можно будет повторно использовать.

---------- Post added at 23:39 ---------- Previous post was at 23:33 ----------

В целом это полный мрак потому что фрагментация быстро достигнет такой длинны что торможение превысит все ожидания

Не только торможение - расход памяти на указатели и "управляющие коды" тоже возрастет. И да, согласен, код сильно усложняется, растет в размере; налаживать трудно.

[bigral]

Этого не избежать, в любом случае придется сдвигать байты на диске. Хоть ты весь файл в оперативку загрузи.

Интересно было бы написать сам редактор отдельным модулем от модуля сохранения. Да еще и на С, тогда бы можно было б портировать везде. К тому же предвижу что потом нужны будут plugin-ы для подсветки;find\replace;соmpare;bin edit by template и т.д.

[SfS]

Для редактора я бы кучу организовал.
Максимальную длину строки ограничил бы 1024 байта, например.
Тогда всё довольно просто - пока в пределах одной строки редактируешь - всё в буфере. Как строку бъёшь - так в куче место выделяется-освбождается. Для 48К накладно, а 128 уже прекрасно.

А вот как проблему загрузки-выгрузки кусками решать - не представляю. Не думал об этом.

[psb]

и мало того, скрипт можно будет и завтра использовать ....

еще раз: только когда знаешь, что искать. ну, и про остальное Barmaley_m уже сказал.