Мастера DELPHI (документация, исходники, скачать)

Основная («Начинающим»)/ Базы / WinAPI / Компоненты / Сети / Media / Игры / Corba и COM / KOL / FreePascal / .Net / Прочее / RSDN.ORG

« предыдущая ветвь | форум | следующая ветвь »

Работая с текстовым файлом

Страницы: 1 2 >
ИМХО © (2004-11-21 16:42:00)
Как узнать текущую позицию?

Ситуация такова: читается текстовый файл от начала и до самого конца (с помощью ReadLn).

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

Как это осуществить?

GuAV (2004-11-21 21:52:00) [1]
TTextRec type

Anatoly Podgoretsky (2004-11-21 19:06:00) [2]
KilkennyCat © (21.11.04 19:04) [26]
Через ReadLn, а именно о нем вопрос, никак. А другие методы это уже не из текстовых файлов.

KilkennyCat (2004-11-21 19:04:00) [3]

> Anatoly Podgoretsky © (21.11.04 19:03) [25]

ну почему же ни как, ежели программно?

Anatoly Podgoretsky (2004-11-21 19:03:00) [4]
ИМХО © (21.11.04 18:15) [22]
Никак, вот если бы это был Д5 тогда было бы одназначно, а начиная с Д6 борланд поше на поводу у некоторыех, теперь абсолютно неясно как и ксолько.

ИМХО (2004-11-21 18:43:00) [5]
кто может это сказать?

KilkennyCat (2004-11-21 18:18:00) [6]
нет.

ИМХО (2004-11-21 18:15:00) [7]

> Anatoly Podgoretsky © (21.11.04 17:15) [9]
> Сумма длин строк + неопределенный разделитель строк, если
> файл верный ,то +1 или 2 в зависимости от системы, только
> для строковых файлов это не верно, у них единица информации
> строка, а не байт.

ВОТ!!!

Выяснилось, что некоторые строки в этих [skipped] файлах заканчивались только на #13, а не на #13#10, а я ко всем приплюсовываю 2!

Но как это узнать программно (без лазания по всему файлу шестнадцатиричном редактором)?

ReadLn не может сказать, чем заканчивается текстовый файл: #13 или #13#10 ???

KilkennyCat (2004-11-21 17:56:00) [8]
С другой стороны, я делал для слабых машин загрузку почти 30 метров в стринглист. пришлость сделать заставку :) зато потом работало шустро.

KilkennyCat (2004-11-21 17:54:00) [9]
В случае больших файлов, да еще на слабых машинах, работать лучше по-другому... через TfileStream, наверное, с собственным обработчиком признаков конца строки и необходимой индексацией для быстрого доступа.

Anatoly Podgoretsky (2004-11-21 17:52:00) [10]
Не предлагаю, а показываю как один из вариантов, на основании твоего разъяснения, которое далеко не полное. Все определяется задачей, но уверен, что это решит проблему скорости, добавления, удаление строк практически на 100%, только при больших размерах стоит задуматься, но это действительно при больших размерах, скажем свыше 10/100 мб на файл.

KilkennyCat (2004-11-21 17:52:00) [11]

> ИМХО © (21.11.04 17:50) [17]

зависит от типа ОС, объема памяти-винчестера, фата...

ИМХО (2004-11-21 17:50:00) [12]

> Anatoly Podgoretsky © (21.11.04 17:42) [16]
> Вся твоя проблема, что ты выбираешь не те средства и алгоритмы
> для выполнения какой то работы. Список наиболее подходящий
> алгоритм.

то есть предлагаешь использовать все-таки TStringList?
файл какого размера он может удержать в памяти? (берем слабенькую машину)

Anatoly Podgoretsky (2004-11-21 17:42:00) [13]
ИМХО © (21.11.04 17:23) [11]
Ну если уж быть совсем строгим, то вообще только один раз в одном направлении, поскольку это может быть последовательный коммуникационный файл, например COM порт, что ты там будешь открывать заново? А это и есть именно определение чистого текстового файла - последовательный, со строками заранее неизвестной длины, разграниченные разделителем, и кончом файла является специальный символ конец файла. В случае файла расположеного на диске просто действует небольшое отклонение от нормы, конец можно определить по размеру, но это чисто частный случай.

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

KilkennyCat (2004-11-21 17:38:00) [14]
TstringList.LoadFromFile - в общем случае, каждый раз, когда изменится файл. Но можно продумать и более удобный вариант, когда меняться будет только измененное...

Anatoly Podgoretsky (2004-11-21 17:36:00) [15]
ИМХО © (21.11.04 17:20) [10]
Во первых если тебе нужна скорость и позионируемость, то загрузи файл в список.

Верный это когда разделитель соответствует системе, а не дика смесь из разных разделителей, например #13#10#10

ИМХО (2004-11-21 17:28:00) [16]

> KilkennyCat © (21.11.04 17:23) [12]

можно подробнее о синхронизации?

KilkennyCat (2004-11-21 17:23:00) [17]
синхронизировав TstringList со свои текстовым файлом ты получишь желаемое удобство и скорость (в зависимости от частоты синхронизации)

ИМХО (2004-11-21 17:23:00) [18]
то есть предлагается запоминать номер строки начала блока, номер строки конца блока, затем КАЖДЫЙ раз открывать файл и читать ReadLn ДО ПОБЕДНОГО?

Жутко неэффективно.

ИМХО (2004-11-21 17:20:00) [19]

> ИМХО © (21.11.04 17:08) [7]
> А почему по этой формуле должно считаться верно?

мне ее Панов давал как-то...

> Сумма длин строк + неопределенный разделитель строк, если
> файл верный

что значит верный?

> зависимости от системы

ось - всегда Винды

Anatoly Podgoretsky (2004-11-21 17:15:00) [20]
ИМХО © (21.11.04 17:08) [7]
А почему по этой формуле должно считаться верно?

ИМХО © (21.11.04 17:10) [8]
Сумма длин строк + неопределенный разделитель строк, если файл верный,то +1 или 2 в зависимости от системы, только для строковых файлов это не верно, у них единица информации строка, а не байт.

Страницы: 1 2 >

Наверх

	« предыдущая ветвь \| форум \| следующая ветвь »