Замена строки в текстовом файле (2 стр)

можно глянуть исходники какого нить текстовика
но там скорее всего чтение файла в память, редактирование, сохранение

dedm0zaj
> но там скорее всего чтение файла в память
А как иначе делать поиск?
Замену-то можно.

Dmitry_Milk
>Зачем писать программу, если можно воспользоваться sed?

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

dedm0zaj
>можно глянуть исходники какого нить текстовика
>но там скорее всего чтение файла в память, редактирование, сохранение

Меньше 2Гб можно читать файлы в память целиком и записывать в одну строку:) А потом пользоваться функциями для работы со строками. Придётся обрабатывать и маркеры конца строки. В линуксовом консольном Редакторе так и сделано. Но там не всё так просто, потому что для обработки кучи файлов нужно ещё и симлинки правильно обработать, чтобы один и тот же файл несколько раз не патчить. Для линукса это сделано, а для переделки под винду нужно аналог функции искать.

А для файлов побольше, или если памяти жалко, придётся грузить в память сегменты файла.

Skvoznjak
> Редактор. Исходники в src.rpm и tar.gz архивах
Напомню, что из себя представляет это изделие изнутри: https://gamedev.ru/flame/forum/?id=11530&page=499&m=5511397#m7476

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

Кстати, обратите внимание. SIMLINKI: byte=1; - это не просто инициализация переменной в единицу. На самом деле - здесь переменная сначала инициализируется в ноль, а только уже потом - к нулю прибавляется единица. Не перепутайте! 🗿

Имбирная Ведьмочка
>Напомню, что из себя представляет это изделие изнутри:

По моему, по сравнению с плюсами, это просто эталон красоты и читаемости кода!

>А при работе с коломбайнами, нужно обязательно соблюдать технику безопасности

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

Вот как в консоли включишь справку sed-а почитать, то сразу возникает труднопреодолимое желание консоль закрыть и больше эту справку не читать:)))))

Имбирная Ведьмочка

>а эти архивы коллекционировать на оптических cd дисках (венчестеры и флешки со временем теряют информацию

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

Имбирная Ведьмочка
> Если старый и новый кусок имеют разную длину - то всё, что идёт после куска,
> придётся сдвигать копированием. Как в векторе, так и в файле.
Вот кстати любопытный момент. Все файлы хранятся в разрозненных кластерах. ОС знает порядок этих самых кластеров. Если к кластеру в теории дописать на сколько байт он заполнен, то можно было бы прямо в API вставить функции добавить/удалить N байт в середине файла. И это был бы крайне полезный функционал для использования. Но почему-то так не сделали.

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

Zab
> надо понимать, что работа с файлами оптимизирована только для последовательного
> доступа
Открываешь файл как FileStream, например:
FileStream fs = new FileStream(strFilePath, FileMode.Create); // С#
Fs := NewReadWriteFileStream(strFilePath); // delphi (KOL для наглядности)
и делай с ним что хочешь без накладных расходов - работаешь с потоком.

flint2
Замерять пробовал, сколько выполняются не последовательные операции?
Работа с потоком вполне себе последовательная, пока ты в нем менять позицию не начнешь.
Беда наступает на всех уровнях, вплоть до контроллера винчестера, оно везде под последовательный доступ оптимизировано. Очень хорошо оптимизировано по многим направлениям. Фактически, система пытается угадать будущие действия и подготовиться к ним заранее, если ей это удается - все быстро.

Zab
> Беда наступает на всех уровнях, вплоть до контроллера винчестера, оно везде под
> последовательный доступ оптимизировано.
Но поток же в памяти и только при закрытии записывается на винт.
Ты же сам писал:
Zab
> Чаще всего перезаписать файл заново выгоднее, чем что-то в нем менять

flint2
> Но поток же в памяти и только при закрытии записывается на винт.
Вообще то, поток в памяти может быть, но то что ты написал им не является. Твой поток - просто оболочка над файловыми операциями.

Zab
> Твой поток - просто оболочка над файловыми операциями.
Ну да, не дописал для краткости, просто подать мысль не загромождая подробностями.
P.S.Zab
> Замерять пробовал, сколько выполняются не последовательные операции?
Такие замеры, но там выполняются ещё хитрые алгоритмы(морфологический и синтаксический анализ) для подготовки данных для обучения сетки, поиск замена подстрок в массиве текстовых файлов ~ 21,17 17,21 ГБ = 38 секунд (компьютер у меня старенький).

Зачем на каждый хелп-вампирский вопрос создавать новую тему?  Есть во флейме же для таких вопросиков - https://gamedev.ru/flame/forum/?id=248221