> > Есть файл А, нужно из него переписать строки в файл Б > в > > обратном порядке, заранее спасибо > 1. Отхватить память = размеру файла. Если файл сильно большой - может не выйти, лучше отмэпить его в память. Тут кстати была когда-то дискуссия по поводу эффективности мэппинга (в майкросовтоском его варианте). Если файл ожидается не сильно большой, то лучше всего будет действительно выделить и считать.
> 2. Прочитать его в память. > 3. Построить индексы (заменить '\n' на '\0' полезно будет > по ходу) Можно открывать файл как текстовый - все \n будут заменяться на \0 если я правильно понял документацию
> 4. Ну и записать в обратном порядке. Можно не строить индексы, а искать strrchr с конца и сразу писать в другой файл
> Если я правильно понял задачу и не заметил подвох. > Должно быть достаточно эффективно, по сравнению с поиском > строк в файле в обратном порядке и записью их.
> Есть файл А, нужно из него переписать строки в файл Б в > обратном порядке, заранее спасибо 1. Отхватить память = размеру файла.
2. Прочитать его в память.
3. Построить индексы (заменить '\n' на '\0' полезно будет по ходу)
4. Ну и записать в обратном порядке.
Если я правильно понял задачу и не заметил подвох.
Должно быть достаточно эффективно, по сравнению с поиском строк в файле в обратном порядке и записью их.
[C++] Смотря насколько большой файл26.02.03 14:08 Автор: amirul <Serge> Статус: The Elderman
> > Есть файл А, нужно из него переписать строки в файл Б > в > > обратном порядке, заранее спасибо > 1. Отхватить память = размеру файла. Если файл сильно большой - может не выйти, лучше отмэпить его в память. Тут кстати была когда-то дискуссия по поводу эффективности мэппинга (в майкросовтоском его варианте). Если файл ожидается не сильно большой, то лучше всего будет действительно выделить и считать.
> 2. Прочитать его в память. > 3. Построить индексы (заменить '\n' на '\0' полезно будет > по ходу) Можно открывать файл как текстовый - все \n будут заменяться на \0 если я правильно понял документацию
> 4. Ну и записать в обратном порядке. Можно не строить индексы, а искать strrchr с конца и сразу писать в другой файл
> Если я правильно понял задачу и не заметил подвох. > Должно быть достаточно эффективно, по сравнению с поиском > строк в файле в обратном порядке и записью их.
[C++] Смотря насколько большой файл27.02.03 10:13 Автор: DPP <Dmitry P. Pimenov> Статус: The Elderman
> Если файл сильно большой - может не выйти, лучше отмэпить > его в память. Тут кстати была когда-то дискуссия по поводу > эффективности мэппинга (в майкросовтоском его варианте). > Если файл ожидается не сильно большой, то лучше всего будет > действительно выделить и считать.
Очень тяжело найти текстовый файл больше, чем размер оперативки.
(Попробуйте пальчиками гигабайт забить. Да что там гигабайт - мегабайт попробуйте. При 100 знаков в минуту - 10000 минут - 166.(6) часов ~7 дней непрерывного стучания днем и ночью и пописать не отойти. А про гигабайт умолчим... Да, и компьютеры с оперативкой, размером меньше 100 мегабайт рассматривать не будем - не тот день на дворе.)
Даже если и больше оперативки - своп, как правило включен.
> Можно открывать файл как текстовый - все \n будут > заменяться на \0 если я правильно понял документацию
Ну это смотря чем читать. Я имел ввиду залпом одним read`ом. Иначе другие проблемы...
> Можно не строить индексы, а искать strrchr с конца и сразу > писать в другой файл
Это уж как удобнее.
Мэпить память в файл не имеет смысла - все равно те же операции.
Наилучший способ обработки файлов считывать их целиком - готов поспорить. Менше накладных расходов на вызов функции чтения при кусочной обработки. Если файл больше оперативки и работы с диском не избежать, то своп грамотнее дисковые операции обработает. К тому же обычно рабочие файлы не рабочем разделе на раиде типа 1 лежат, а своп на раид типа 0 направлен. Хочется, чтоб быстрее сработало, просто добавь модуль памяти - в оперативке уместится - в десяток раз быстрее будет. Писал я как-то библиотечку для работы с файлами базы данных таким образом (а не чтение по записям) - летала, как самолет.
Urix`у - пятерка, алгоритм простой и эффективный, вот только накладные расходы на позиционирование (lseek).
[C++] Я ж не сам придумал, а на основе обсуждения и собственного опыта27.02.03 12:11 Автор: amirul <Serge> Статус: The Elderman
> Даже если и больше оперативки - своп, как правило включен. У меня он как раз выключен, хотя бы для того чтоб проги с XML-ным интерфейсом не сильно тормозили
> > Можно открывать файл как текстовый - все \n будут > > заменяться на \0 если я правильно понял документацию > > Ну это смотря чем читать. Я имел ввиду залпом одним > read`ом. Иначе другие проблемы... Я тоже имел в виду залпом, но одним fread-ом.
> Мэпить память в файл не имеет смысла - все равно те же > операции. А вот эта тема как раз очень тщательно обсасывалась и не имеет смысла еще раз делать то же самое. Единственное резюме: мэппинг в майкрософтовской реализации ведет себя мягко говоря, странно. Здесь даже проходила фича еще по одному связанному с этим вопросу: если делать CreateFile без кэширования, то (не мои слова: почем купил - за столько и продаю - не проверял) скорость его обработки возрастает чуть ли не в 3 раза.
> Urix`у - пятерка, алгоритм простой и эффективный, вот > только накладные расходы на позиционирование (lseek). Это да
[C++] И такие бывают27.02.03 10:42 Автор: Ktirf <Æ Rusakov> Статус: Elderman
> Пара пустяков. У меня тут валяется несколько > XML-описаний...
Я не спорю с тем, что такие файлы бывают и их даже можно найти.
Но это редкость.
> Ну кто ж такие вещи пальчиками делает. Слава Богу, в UNIXах > программ, генерящих текстовый выход, предостаточно.
И как часто такие файлы "переворачивать" надо?
Вы не пробовали просто прочитать документацию на несколько сотен килобайт, я уж про несколько сотен мегабайт не говорю.
И, вообще, когда речь идет о программе/алгоритме и не требуется заказчиком в постановке задачи ограничение на объем памяти, то в решении на это упор ставить не следует.
Даже если эта программа будет использоваться на практике на современных компьютерах, то для подавляющего большинства файлов она сработает. По крайней мере, я сомневаюсь, что когда-нибудь в процессе работы пользователь увидит сообщение типа: "Для обработки данного файла мало оперативной памяти, добавте, пожалуйста [столько-то] и повторите попытку".
[C++] Ну собственно и документацию переворачивать очень редко приходится :-))27.02.03 12:03 Автор: amirul <Serge> Статус: The Elderman
> Я не спорю с тем, что такие файлы бывают и их даже можно > найти. > Но это редкость. > > > Ну кто ж такие вещи пальчиками делает. Слава Богу, в > UNIXах > > программ, генерящих текстовый выход, предостаточно. > > И как часто такие файлы "переворачивать" надо? Как раз потому, что файл надо перевернуть - он скорее всего сгенеренный. Почти во всем, набранном человеком очень важен исходный порядок строк
А насчет большого файла. Это я с фаром намучался. Уж не помню стандартный просмотрщик или редактор, но он загоняет весь файл в память целиком, а мне иногда и бинарник надо подправить символ-другой
А вообще. Алгоритмы найдены. Дальше это простой флуд. Предлагаю закрыть
подробно о проекте
Анализ криптографических сетевых...
новое сообщение
закрытая нитка
новое сообщение
в закрытой нитке
старое сообщение
