|
ru.algorithms
- RU.ALGORITHMS ----------------------------------------------------------------
From : Sergey Andrianov 2:5020/1507.400 05 Apr 2002 21:40:36
To : Valentin Davydov
Subject : Re: структура данных в файле
--------------------------------------------------------------------------------
Однажды 05-Apr-02 в 20:20 Valentin Davydov (via gate)
написал Sergey Andrianov по поводу
-=- Re: структура данных в файле -=-
>VD>> >Kак идеологически правильно сохранять данные в файле?
>>
>VD>> Идеологически правильно хранить данные (если их не очень много) в виде
>VD>> последовательности ASCII строк переменной длины, заканчивающихся символами
><LF>>> или <CR><LF>. Пустые строки игнорируются, если в строке встретился
>>
>VD>> Все другие форматы идеологически неправильны, в том смысле, что либо
>VD>> требуют чрезвычайно детального (многостраничного, как png) описания
>VD>> формата, либо приводят к непропорциональным проблемам портирования, и
>VD>> без весьма серьёзных на то оснований (грошовая экономия места и времени
>VD>> к таковым обычно не относятся) пользоваться ими не стоит.
>>
>> Да...
>> У меня товарищ поначалу тоже пытался хранить данные в виде ASCII строк.
VD> >Kаждый раз при запуске программа работала 3 минуты (а ему надо было
VD> отсчитать >несколько сотен вариантов).
VD> Kто ж виноват, что твой товарищ программировать не умеет?
А я этот пример и привел именно в таком качестве.
Более того, я то же самое могу сказать о человеке, который не умеет работать
ни с какими данными кроме текстовых.
VD> Если критична
VD> скорость, то надо считывать файл только один раз, а не несколько сот.
K сожалению, это далеко не всегда возможно. В данном конкретном случае
файлов, которые нужно читать, было более 700, и в каждом варианте требовался
определенный их набор, кстати, также формировавшийся программно и описываемый в
конфигурационном файле.
Я надеюсь, излишне говорить о том, что все файлы во много раз превосходили
доступный объем ОЗУ, так что считыванию данных для каждого варианта отдельно
трудно было придумать альтернативу.
>> Посуди сам, как бы выглядел, скажем bmp-файл, если бы данные в нем
VD> хранились
VD> >по предложенному тобой способу:
VD> Hаверное, как png. Поскольку этот формат не надо изобретать, он полностью
VD> документирван и есть библиотеки. Да к тому же он ещё и компактнее, чем bmp.
Хорошо, GIF, JPG...
>> Kроме некоторых частных случаев данные должны храниться в бинарном виде,
VD> >так, как они хранятся в памяти, чтобы не было необходимости в
VD> преобразовании >при считывании.
VD> Это хорошо, когда данные - последовательность независимых байт, или когда ты
VD> читаешь той же программой (ну, или, по крайней мере, собранной тем же
VD> компилятором с теми же хедерами и библиотеками под той же ОС на том же
VD> компьютере), которой писал. А когда данные имеют более сложную структуру
VD> (слова или, не дай Бог, плавающая точка), тут-то и начнаются всякие
VD> заморочки про big/little endian, детали реализации malloc() в разных
VD> системах и откуда начинаются массивы в разных языках.
Представь, работал с смешанными данными (double(8),single(4), text,
integer(4), и, кроме того, с нестандартным форматом real(2)) при этом и считывал
и записывал их как на IBM PC, так и на Alpha, естественно, в разных ОС. И -
никаких проблем. Естественно, ?endian надо учитывать, ну так это входит в
описание формата. Kстати, даже с применением уже упомянутого нестандартного
двухбайтового с плавающей точкой объем данных для одного варианта составлял
более 1Гбайта. Представь, сколько бы это занимало места и сколько времени
уходило бы на чтение/запись при текстовом представлении информации.
Так что уникальные форматы файлов вполе имеют право на существование,
естественно, они должны быть хорошо документированы, включая порядок байтов в
многобайтовых величинах.
До свидания, в 21:21 MSK
Sergey
---
* Origin: Sergiev Posad (2:5020/1507.400)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
