Пипец умнюк, одно дело собирать из двух кусков, другое дело одним куском записать и не париться.Цитата:
Сообщение от ZEK
Для неврубающихся: лично я хранение текста построчно в куче даже и не рассматриваю.
Вид для печати
Пипец умнюк, одно дело собирать из двух кусков, другое дело одним куском записать и не париться.Цитата:
Сообщение от ZEK
Для неврубающихся: лично я хранение текста построчно в куче даже и не рассматриваю.
собрать это написать процедурину?Цитата:
Сообщение от Vitamin
Нет. Выполнить некую процедуру по преобразованию текста из внутреннего формата в пригодный для последовательного сохранения на блочном носителе.Цитата:
Сообщение от ZEK
Если ты говоришь о необходимости писать специальный код для этого преобразования, то ситуация следующая.
Для классического варианта преобразования не требуется.
В альтернативных вариантах преобразование делается имеющимся функционалом. Для хранения текста в виде двух частей- временным переходом на границу текста, для хранения текста в куче- последовательным проходом. Эта функциональность тоже необходима (хотя бы для навигации по тексту).
То, что второй вариант на порядок сложнее- и ежу понятно.
То есть делаем вывод, различие вариантов когда текст уже плоский и вариант когда он состоит из двух кусков состоит из вызова из одной процедуры, следовательно как критерий упрощения записи вариант с плоских хранением очень сомнителен, выигрыш в длительности операции записи, но на фоне операций IO это не заметно, и тут стоит склоняться к варианту где работа в типовых операциях менее накладная и отзывчивая со стороны UI
В худшем случае копируется 255=размер_блока-1 байт (если окно меньше, то два раза). Кстати, никто не заставляет сохранять, если свободное окно между кусками меньше размера блока. Например, ACEdit может редактировать 65535 байт, но он не сохранит, если больше 65280.Цитата:
Сообщение от Vitamin
А тут уже расходятся мнения что считать "типовой операцией"- навигацию или редактирование.Цитата:
Сообщение от ZEK
Вот накидал оценки затрат:
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)
Мог чего не учесть, прошу поправлять:)
оценивать только время работы с текстом в отрыве от юзер интерфейса мало смысла !
не стоит забывать что за компом сидит юзер, и этот юзер имеет некие ожидания скорости ответа компьютера
типа:
вставка/удаление символа : "Мгновенно" (он совершенно спокойно может набирать в слепую)
переход на строку вверх/вниз "Мгновенно", (он смотрит на экран, помнит его содержимое, новые данные анализировать не надо)
Страница ввер/низ : "быстро" (на экране новая инфомация, надо потратить время на ее анализ)
Начало/Конец текста "достаточно быстро" (контекст сильно изменяется, нужно только в специальны случаях)
сервисные операции (запись/поиск/etc) "желательно быстро" операции тяжелые, сложные, можно и подождать)
т.е. например пауза в 1/3 секунды при вооде символа вообще не приемлема
пауза в пару секунд при записи - терпимо
и по посту, а разве для Two part - Edit не O(1) ?
причем в любом случае, это скорость ВСЕГО редактора, с отрисовкой и прочим.
голая математика тут мало подходит, это комплекс решений ....
Вообще-то те алгоритмы что доступны для 8bit процов спокойно могут быть реализованны практически на ВСЕХ компах. Одним блоком желательно иметь ВСЕГДА И ВЕЗДЕ и любые данные. К тому же описанный метод своего рода "замена" классических одно-двухсвязных списков которая даст им фору по памяти и по сложности обслуживающих алгоритмов.Цитата:
Сообщение от esl
Использование буфера. Оно же поможет с автоформатированием.Цитата:
Сообщение от esl
Про конец соглашусь, про начало- нет. Переход на начало чисто психологически должен быть мгновенным.Цитата:
Сообщение от esl
О! Кстати о поиске. Для него накладные расходы вообще должны отсутствовать.Цитата:
Сообщение от esl
С чего это? Данные разве не надо положить?Цитата:
Сообщение от esl
Отредактировал оценку перехода на конец для plain text. Таки это надо отсчитать строки от конца.
Да, могут сказаться опущенные в "о большое" коэффициенты. Только узнать это можно одним способом- взять и сделать. Так что не слушай никого, бери и пробуй:)Цитата:
Сообщение от esl
а с того что надо что надо спросить у пользователя что искать, etc, etc,Цитата:
Сообщение от Vitamin
есть дополнительное взаимодействие ...
есть указатель на "Курсор"Цитата:
Сообщение от Vitamin
в него поместили байт
увеличели X и указатель
все