Cтраница 2
Еще раз обращаю ваше внимание на то, что логика управления соответствует основным функциям. Введенные в меню дополнительные пункты реализуются без изменения файла процедур. Не включены функции резервного копирования / восстановления BACKUP. [16]
Нетрудно убедиться в том, что все перечисленные программы обращаются к общим для них подпрограммам. Происходит это либо непосредственно по команде DO с передачей параметров, либо с помощью файла процедур. Первоначально подпрограммы были реализованы в виде самостоятельных программ, но впоследствии стало ясно, что незачем хранить на диске их множественные дубликаты, поскольку отличались они только именами файлов FRAMER, GETTER, DBF и NDX. Последнее и натолкнуло меня на мысль создать библиотеку. [17]
В файл процедур не включена еще одна подпрограмма. Я часто ею пользуюсь, и поскольку не всегда можно знать, какой из файлов процедур активен, эту подпрограмму можно размещать непосредственно в теле программы. [18]
В случае объединения отдельные программы располагаются обычно в последовательности обращения к ним. Такой подход не свободен от недостатков: при неоднократном обращении к каким-то подпрограммам исходная программа очень быстро окажется запутанной. Наличие механизма файлов процедур может помочь решить данную проблему: часто вызываемые программы объединяются в отдельный файл. [19]
Обособленное хранение подпрограмм на диске упрощает их использование в различных приложениях. Поскольку каждая подпрограмма полностью оттестирована и универсальна, привязка к проекту обычно не требуется. Составляется перечень необходимых подпрограмм, вносятся ( обычно минимальные) корректировки и, наконец, определяется, какие файлы целесообразно объединить в файл процедур. По окончании разработки новая подпрограмма заносится в библиотеку, причем она сопровождается внешней документацией, где указываются назначение, область применения и прочие сведения. [20]
Рассмотренный выше пример позволяет выявить и некоторые дополнительные возможности файлов процедур. Обратите внимание на то, что я далеко не всегда передаю параметры в вызываемые подпрограммы. При работе с процедурными файлами это совершенно не обязательно. Гибкость - полезное свойство, но необходимо помнить следующее: если подпрограмма, реализованная в рамках файла процедур, может вызываться из различных точек программы или несколькими программами, команды вызова должны быть согласованы как по числу передаваемых параметров, так и по типу их значений. [21]
Следует избегать рекурсивного вызова процедур, т.е. вызова из процедуры этой же процедуры. Процедуры можно помещать вместе с главной процедурой или отдельно в специальный файл процедур, в котором может размещаться до 1170 процедур. Практическим ограничением на число процедур обычно выступает емкость оперативной памяти, в которой размещается для выполнения как программный файл, так и файл процедур. В начале каждого объектного модуля помещается список процедур, которые в нем используются независимо от того, находятся ли они вместе с главной процедурой программы или в процедурном файле. В этот список первым ьходит и сама главная процедура под именем программного файла. [22]
Сборку работоспособной версии программы выполняет второй компонент рассматриваемой подсистемы - компоновщик DBL. Процесс сборки напоминает редактирование, с которым встречался каждый, кто компилировал какие-либо программы. После перевода ряда программ на псевдокод отдельные модули предстоит собрать в общий файл, где они окажутся связанными в единое целое. При этом модули должны не только располагаться рядом, но и включать адресные ссылки на вызываемые модули. Так, некоторая программа может несколько раз обращаться к различным подпрограммам, собранным в файл процедур. В результате псевдокомпиляции и компоновки главной программы и файла процедур мы получаем единый файл. В процессе компоновки здесь формируется таблица адресов, по которым можно передавать управление подпрограммам ( инструкция JUMP), а после завершения их работы - возвращать управление ( инструкция RET) в нужную точку ( ее адрес определяется по стеку) главной программы. [23]
Сборку работоспособной версии программы выполняет второй компонент рассматриваемой подсистемы - компоновщик DBL. Процесс сборки напоминает редактирование, с которым встречался каждый, кто компилировал какие-либо программы. После перевода ряда программ на псевдокод отдельные модули предстоит собрать в общий файл, где они окажутся связанными в единое целое. При этом модули должны не только располагаться рядом, но и включать адресные ссылки на вызываемые модули. Так, некоторая программа может несколько раз обращаться к различным подпрограммам, собранным в файл процедур. В результате псевдокомпиляции и компоновки главной программы и файла процедур мы получаем единый файл. В процессе компоновки здесь формируется таблица адресов, по которым можно передавать управление подпрограммам ( инструкция JUMP), а после завершения их работы - возвращать управление ( инструкция RET) в нужную точку ( ее адрес определяется по стеку) главной программы. [24]