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

[Vitamin]

Это не проблема. Перед сохранением, перемещаем курсор в конец текста. Это один вызов уже существующей в редакторе функции. Это объединяет текст в один блок.

Но ведь это уже обработка. Конечно, ее можно минимизировать, вычислив оптимальную сторону куда прыгать (в начало или в конец), но в общем случае она есть.

Эти способы по любому проще сохранения из кучи.

Понятное дело.

Кстати, была мысль при укорачивании строк не уплотнять весь текст, а оставлять окно, пометив его какими-нибудь кодами. Потом при поиске свободного места можно в обе стороны бегать уплотняя построчно.

[Advertiser]

[ZEK]

Но ведь это уже обработка.

Пипец задрот, одно дело из кучи собирать в буфер и записывать (а каждый очередной кусок может выходить за пределы буфера и это дополнительный танец), то ли переместить курсор в хвост, и сохранить одним куском

[Vitamin]

Пипец задрот, одно дело из кучи собирать в буфер и записывать (а каждый очередной кусок может выходить за пределы буфера и это дополнительный танец), то ли переместить курсор в хвост, и сохранить одним куском

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

Для неврубающихся: лично я хранение текста построчно в куче даже и не рассматриваю.

[ZEK]

одно дело собирать из двух кусков

собрать это написать процедурину?

[Vitamin]

собрать это написать процедурину?

Нет. Выполнить некую процедуру по преобразованию текста из внутреннего формата в пригодный для последовательного сохранения на блочном носителе.

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

[ZEK]

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

[alone]

С учетом того, что разделение делается в произвольном месте, а ввод-вывод у нас блочный, над стыком таки потребуется дополнительная обработка. И она будет сложнее, если свободное окно между кусками меньше размера блока. Я в чем-то ошибся? Если да, то в чем?

В худшем случае копируется 255=размер_блока-1 байт (если окно меньше, то два раза). Кстати, никто не заставляет сохранять, если свободное окно между кусками меньше размера блока. Например, ACEdit может редактировать 65535 байт, но он не сохранит, если больше 65280.

[Vitamin]

и тут стоит склоняться к варианту где работа в типовых операциях менее накладная и отзывчивая со стороны UI

А тут уже расходятся мнения что считать "типовой операцией"- навигацию или редактирование.

Вот накидал оценки затрат:
M - размер текста
N- средний размер строки
K- размер экрана в строках

Учтены разумные оптимизации (например, известный конец текста).

       \Метод| Plain | Twopart | Fragmented
Операция\    | text  |  text   |   text
-------------------------------------------
Home         | O(1)   | O(M)   | O(1)
End          | O(N*K) | O(M)   | O(1)
LineUp       | O(N)   | O(N)   | O(1)
LineDn       | O(N)   | O(N)   | O(1)
PgUp         | O(N*K) | O(N*K) | O(K)
PgDn         | O(N*K) | O(N*K) | O(K)
Edit         | O(M+N) | O(N)   | O(N)

Умножаем веса для каждой из операций на матрицу и получаем трудоемкости для каждого из методов.

Мог чего не учесть, прошу поправлять

[esl]

оценивать только время работы с текстом в отрыве от юзер интерфейса мало смысла !
не стоит забывать что за компом сидит юзер, и этот юзер имеет некие ожидания скорости ответа компьютера
типа:
вставка/удаление символа : "Мгновенно" (он совершенно спокойно может набирать в слепую)
переход на строку вверх/вниз "Мгновенно", (он смотрит на экран, помнит его содержимое, новые данные анализировать не надо)
Страница ввер/низ : "быстро" (на экране новая инфомация, надо потратить время на ее анализ)
Начало/Конец текста "достаточно быстро" (контекст сильно изменяется, нужно только в специальны случаях)
сервисные операции (запись/поиск/etc) "желательно быстро" операции тяжелые, сложные, можно и подождать)

т.е. например пауза в 1/3 секунды при вооде символа вообще не приемлема
пауза в пару секунд при записи - терпимо

и по посту, а разве для Two part - Edit не O(1) ?

причем в любом случае, это скорость ВСЕГО редактора, с отрисовкой и прочим.

голая математика тут мало подходит, это комплекс решений ....

[Vitamin]

вставка/удаление символа : "Мгновенно" (он совершенно спокойно может набирать в слепую)

Использование буфера. Оно же поможет с автоформатированием.

Начало/Конец текста "достаточно быстро" (контекст сильно изменяется, нужно только в специальны случаях)

Про конец соглашусь, про начало- нет. Переход на начало чисто психологически должен быть мгновенным.

сервисные операции (запись/поиск/etc) "желательно быстро" операции тяжелые, сложные, можно и подождать)

О! Кстати о поиске. Для него накладные расходы вообще должны отсутствовать.

и по посту, а разве для Two part - Edit не O(1) ?

С чего это? Данные разве не надо положить?
Отредактировал оценку перехода на конец для plain text. Таки это надо отсчитать строки от конца.

голая математика тут мало подходит, это комплекс решений ....

Да, могут сказаться опущенные в "о большое" коэффициенты. Только узнать это можно одним способом- взять и сделать. Так что не слушай никого, бери и пробуй