ну сосбтвенно в работе это уже лет как 25+ можно посмотреть в МикроМире ;)
Вид для печати
ну сосбтвенно в работе это уже лет как 25+ можно посмотреть в МикроМире ;)
В порядке обсуждения, чисто теоретическая идея. Показываю на интуитивнопонятном примере:
Строка до правки:
"Моя Родина - Союз Советских Республик!"
Строка после правки:
"Моя Родина - Союз Советских Социалистических Республик!"
Как должно выглядеть:
Состояние памяти до правки:
адрес_1: "Моя Родина - Союз Советск"
адрес_2: "их "
адрес_3: "Республик!"
адрес_4:
Состояние памяти после правки:
адрес_1: "Моя Родина - Союз Советск"
адрес_2: [управляющий код][адрес4]
адрес_3: "Республик!"
адрес_4: "их Социалистических "[управляющий код][адрес_3]
(управляющий код и адрес занимают 3 байта)
Плюсы:
Не нужно двигать текст вообще.
Минусы:
Вероятно, усложняется и замедляется процедура вывода текста на экран.
Перед сохранением текста необходима дополнительная обработка.
Sergey, Хорошая годная трава.
только зачем?
Это некий вид односвязного списка с выделением памяти в конце редактируемого буфера. Если у Вас возникла иллюзия что память тут выделяется как на стеке (типо она якобы заранее выделенная и потому все быстро) то это неправда, т.к. в отличие от стека тут фрагментация дикая будет и вообще самый примитивный по реализации malloc так и работает. В целом это полный мрак потому что фрагментация быстро достигнет такой длинны что торможение превысит все ожидания а дефрагментация потребует диких обьемов кода\временного буфера.
ага, на практике даже во много итераций но скриптом анализировать проще
просто у скрипта сильо больше возможностей править логи
и мало того, скрипт можно будет и завтра использовать ....
опять же, это для меня, и я достаточно давно в эти игры играю
мне проще написать скрипт в пару строк чем в редакторе править руками
да и поиск/замена в редакторах (даже так реализована как в с Sublime text 2) - бледное подобие возможностей скрипта
Это оффтопик, но раз уж сам модератор его поддерживает, то я не могу не ответить. Иногда баги в софте, который пишет лог, таковы, что правила правки лога сложно формализовать в виде скрипта. Может получиться так, что скрипт превратится в парсер лога с конкретными нарушениями структуры с последующей генерацией исправленного лога. Огромный объем кода. Также появляется необходимость отладки скрипта и его проверки, что он не портит лог где-то, где этого совсем не ждешь. Ладно если баг в скрипте приведет к синтаксической ошибке в логе, что парсер лога впоследствии выругается. А если произойдет незаметная порча данных? В моей практике, когда объем правок невелик, а формализация затруднена, как правило было удобнее редактировать логи вручную.
Сам по себе такой скрипт, как правило, не подлежит повторному использованию, т.к. баг в программе, записавшей лог, фиксится, так что таких же ошибок в следующих логах уже не будет. Только опыт, полученный при написании и наладке скрипта, можно будет повторно использовать.
---------- Post added at 23:39 ---------- Previous post was at 23:33 ----------
Не только торможение - расход памяти на указатели и "управляющие коды" тоже возрастет. И да, согласен, код сильно усложняется, растет в размере; налаживать трудно.
Для редактора я бы кучу организовал.
Максимальную длину строки ограничил бы 1024 байта, например.
Тогда всё довольно просто - пока в пределах одной строки редактируешь - всё в буфере. Как строку бъёшь - так в куче место выделяется-освбождается. Для 48К накладно, а 128 уже прекрасно.
А вот как проблему загрузки-выгрузки кусками решать - не представляю. Не думал об этом.