Всего-то работа с логами ...

From

Alex Astafiev (2:5000/228.16)

To

Stanislav Latishko

Date

2003-01-09T00:49:58Z

Area

RU.ALGORITHMS

 SL>>     Я только не понял - что даст фиксированная длина ? Можно все
 SL>> записи добить пробелами до максимальной - это даст увеличение
 SL>> размеров раза в полтора. За возможность сразу найти запись по
 SL>> номеру - дороговато. Ссылки на "ту же тему" - так ведь "тема"
 SL>> заранее не определена, она выяс- няется уже в процессе просмотра
 SL>> ... А поначалу - валится вся информация, которая _может_
 SL>> содержать что-то "интересное".
 NAS>
 NAS> Не могу себе представить ситуацию, когда 'тема заранее неопределена'.
 NAS> IMHO грабли потеряны где-то рядом. Неужели нельзя например разбить
 NAS> систему "интерфейсами" на "отдельные блоки" и проверить исправности
 NAS> всех блоков поотдельности?

неясно, сколько можно мусолить эту тему.
какой тут может быть еще вариант, кроме как загружать файл по частям (ехать по
нему окном в 100-1000кб) и работать с этой частью?

лог обьемом в несколько GB, а *nix/win32 имеют только 2Gb пользовательского
virtual adress space, да и любая загрузка сходного обьема в память вызовет
всего -лишь перераспределение информации в pagefile (своп).

Используй функции memory-mapped файлов.
Я бы сделал такую абстракцию, чтобы выражать позицию в виде __int64 (или
struct{int pos1; int pos2; } pos;) и ездил бы
себе на здоровье по своему "виртуальному" файлу взад-вперед.
А реализацию виртуального файла бы сделал такой, что она мне "прозрачно"
"кэшировала", смэпливала бы участок в N килобайт. Вот и все дела.

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


---
 * Origin: Фидонет - сеть друзей. Будьте дружественнее! (2:5000/228.16)