| Предыдущая глава |
↓ Содержание ↓
↑ Свернуть ↑
|
к каждой такой записи, описывающей одно поле, прилагалось еще и его значение.
Что значит "прилагалось"? Надо уточнить. Пока что я это понимаю так, что
вот у меня есть открытый файл (поток); его указатель чтения/записи указывает на
некоторый его элемент; этот самый элемент (запись разумеется) уже считан и
находится в связанным с этим файлом буфере. А каждая запись метапотока имеет
указатель на то поле этого буфера, которое описывает. На предмет получения
оттуда содержащегося в этом поле значения.
Ага-ага: теперь надо уточнять, что значит здесь слово "получение"?
Ну как "что" — вот например у нас есть файл (поток) открытый под
псевдонимом П; под псевдонимом Q открываем его метафайл: Ope () П; Ope %M Q
и теперь написав что-то типа: Ope QS; Write %M; Ope %; получаем нечто типа:
@имя_метафайла :имя_поля1 = значение1 :имя_поля2 = значение2 .... ! (или ;
и продолжение в следующих строках — если не поместилось в одну). Где после
знака = (равно) — содержимое соответствующего поля из текущей записи файла,
открытого под псевдонимом П. Ага.
Сделать то вот такое для одного этого частного случая вполне можно. А для
общего? Для общего получается, что эти самые "значения" — значения одного и
того-же поля. Уж не знаю (пока) как оно называется, но не слишком ли круто?
Получается, что у каждой записи метафайла это поле будет разное — в точности
того типа, как описывается самой этой записью. Ну и что, что метафайл -
виртуальный. Договорились же, что в потоке записей, все записи одинаковые!
Ну ладно, пусть таки это поле типа указатель на поток из одного элемента.
При чем со свойством автоматического разыменования, как в Си-плюс-плюсе то ли
"указатель" то ли "ссылка" (вечно я названия этих адресных типов путаю).
Ха! А как он вообще выглядит, этот самый "общий случай"? Как... Ну например
мы откроем вот этот вот мета-файл, найдя его в оном виртуальном каталоге
мета-файлов. Пока правда не знаю как это сделать. В смысле как переключить на
него канал "Д", но возможно придумаю. И тогда, спрашивается, на какие именно
поля какого из нескольких сответствующих данному метафайлу потоков будут
направлены все эти ссылки? Учитывая, что может их и вправду несколько, а может
и ни одного — все уже закрыты или еще даже не открывались (и/или даже и не
созданы), но было заранее введено описание...
О котором я опять благополучно забыл!
Ну в общем — да: получается что метафайл сам по себе, но будучи открыт, он
всегда связан с каким-то конкретным файлом, или же пока ни с каким — тоже
виртуальным — только чтобы было где хранить начальные значения, буде они
указаны в описании. Форму и вид которого я так старательно отлыниваю придумать.
Придумать осталось каким образом обозначаем параметры поля. Имя это имя,
оно после двоеточия обязательно первое. Значение всегда последнее — после знака
= (равно). А вот остальные параметры...
— номер по порядку — например #число
— смещение от начала записи — например +число
— размер поля — например *число
— тип поля — например /буковка (пусть такая же как в .dbf)
— комментарий — после ; или ! и до конца строки
Пусть там где нужно число, может быть числовое выражение в любых скобках, а
там где буковка... Вот если бы нам надо было ограничиться только файлами типа
.dbf то позаимствовали бы оттедова оные буковки и всё:
"C" — символьное
"N" — числовое
"L" — логическое
"D" — дата (типа: ГГГГММДД)
"F" — число с плавающей запятой
"M" — "мемо" — хранящийся где-то отдельно текстовый комментарий (вернее десять
цифр — его адрес в файле типа .dbt)
Вот только для общего случая этого категорически недостаточно. Потому что
например число здесь вовсе не двоичное, а последовательность цифр. И вообще
похоже, что этот самый .dbf (вернее его основной поток) типа насквозь текстовый.
И вот с помощью этого не получится как-то описать даже заголовок самого этого .
dbf-овского файла.
И, кстати, в форматном преобразовании (это которое "еще более форматное",
чем само форматное выражение оператора Write %): ={X%формат} и #{Y%формат}
у нас вообще-то примерно такая же проблема. А еще хочется, чтобы буковки,
обозначающие типы здесь и форматы там были одни и те же или хотя бы как-то
между собою согласованы. А там у нас — буковки, позаимствованные у Сишных
функций printf() и scanf() (с их же помощью и реализовано):
d i o u x — целое число (десятичное, 8 и 16-ричное, беззнаковое...)
b — тоже целое, но бинарное
e f g — плавающее
c s — символы
При ближайшем рассмотрении ни то ни то нам не годится. Подходит только в
первом приближении: у printf() и scanf() формат должен описывать в том числе
и аргументы этих функций, а нам этого не надо: у нас тип значения один
единственный. Поэтому нам надо только то, во что их преобразовать. Так что
буковки d o x b обозначающие десятичное, восьмеричное, шестнадцатиричное и
двоичное (какового, кстати у printf() и scanf() нет) — да, пригодятся. А вот
"u" указывающая что аргумент беззнаковый... Или "i"... Ха, это только при
выводе "i" дублирует "d", а при вводе он распознаёт числа вида 0xNNN 0NNN 0bNNN.
Однако, эту миссию поручим таки "N", а "i" и "u" пусть обозначают бинарное
целое — со знаком и без. (Со знаком — в дополнительном коде.) А "f" — тоже
бинарное число с плавающей запятой. А вот по поводу нетандартной упаковки
мантисы и порядка... Подумаем.
Текстовое поле фиксированной длины (например 15 симовов): %15C а вот %15S
это будет строка со служебными символами, типа обрамляющих её кавычек, а так
же экранирующих... Которые, кстати, могут быть очень даже разные: в Си и в
UNIX`е это (обратная косая черта), у нас шаблонах — % (процент)... Так что
этот механизм тоже должен быть в некоторой степени настраиваемым... Подумаем.
Вообще с полями фиксированного размера проблем нет (указывается числовой
константой), а вот как быть если он — переменного? При чем у нас имеет место
быть два варианта (даже три): либо размер указывается некоторым другим полем,
либо его границы обозначаются некоторыми конструкциями — от одиночного символа
'n' как в UNIX`овских текстовых файлад, до достаточно сложных конструкций,
вот как в .xml: <тег>......
продолжение следует
| Предыдущая глава |
↓ Содержание ↓
↑ Свернуть ↑
|
