|
ru.algorithms
- RU.ALGORITHMS ----------------------------------------------------------------
From : Valentin Davydov 2:5020/400 05 Apr 2002 20:20:27
To : Sergey Andrianov
Subject : Re: структура данных в файле
--------------------------------------------------------------------------------
> From: Sergey Andrianov
> <Sergey.Andrianov@p400.f1507.n5020.z2.fidonet.org>
> Date: Mon, 01 Apr 2002 21:01:38 +0400
>
>VD> >Kак идеологически правильно сохранять данные в файле?
>
>VD> Идеологически правильно хранить данные (если их не очень много) в виде
>VD> последовательности ASCII строк переменной длины, заканчивающихся символами
><LF>> или <CR><LF>. Пустые строки игнорируются, если в строке встретился
>
>VD> Все другие форматы идеологически неправильны, в том смысле, что либо
>VD> требуют чрезвычайно детального (многостраничного, как png) описания
>VD> формата, либо приводят к непропорциональным проблемам портирования, и
>VD> без весьма серьёзных на то оснований (грошовая экономия места и времени
>VD> к таковым обычно не относятся) пользоваться ими не стоит.
>
> Да...
> У меня товарищ поначалу тоже пытался хранить данные в виде ASCII строк.
>Kаждый раз при запуске программа работала 3 минуты (а ему надо было отсчитать
>несколько сотен вариантов).
Кто ж виноват, что твой товарищ программировать не умеет? Если критична
скорость, то надо считывать файл только один раз, а не несколько сот.
> Посуди сам, как бы выглядел, скажем bmp-файл, если бы данные в нем хранились
>по предложенному тобой способу:
Hаверное, как png. Поскольку этот формат не надо изобретать, он полностью
документирван и есть библиотеки. Да к тому же он ещё и компактнее, чем bmp.
> Kроме некоторых частных случаев данные должны храниться в бинарном виде,
>так, как они хранятся в памяти, чтобы не было необходимости в преобразовании
>при считывании.
Это хорошо, когда данные - последовательность независимых байт, или когда ты
читаешь той же программой (ну, или, по крайней мере, собранной тем же
компилятором с теми же хедерами и библиотеками под той же ОС на том же
компьютере), которой писал. А когда данные имеют более сложную структуру
(слова или, не дай Бог, плавающая точка), тут-то и начнаются всякие заморочки
про big/little endian, детали реализации malloc() в разных системах и откуда
начинаются массивы в разных языках.
Вал. Дав.
--- ifmail v.2.15dev5
* Origin: St. Petersburg State University (2:5020/400)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
