Тема 3.4.1 Трансляция модуля. Создание выполнимой программы

END.

BEGIN

ИНИЦИАЛИЗАЦИОННАЯ ЧАСТЬ

РЕАЛИЗАЦИОННАЯ ЧАСТЬ

IMPLEMENTATION Начало раздела реализации;

USESИспользуемые при реализации модули;

LABEL Подраздел объявления скрытых глобальных меток;

CONST Подраздел объявления скрытых глобальных констант;

TYPE Подраздел объявления скрытых глобальных типов;

VAR Подраздел объявления скрытых глобальных переменных;

PROCEDUREТела доступных и скрытых процедур;

FUHCTIOH Тела доступных и скрытых функций;

Основной блок модуля;

2.1 Заголовок модуля

Заголовок модуля мало отличается от заголовка программы. В модуле вместо зарезервированного словаPROGRAM используется слово UNIT. Здесь же могут присутствовать директивы компилято­ру, дающие общие установки/соглашения для всего модуля.

При выборе имени модуля необходимо учитывать одну особен­ность. Выбирая имя программы, мы заботились о том, чтобы оно не совпадало с именами объектов (процедур, функций и т.п.) внутри программы. Здесь к этому требованию добавляется еще и требование совпадения имени модуля с именем файла, в котором он хранится. Поэтому имя модуля не может состоять более чем из восьми символов.

2.2 Интерфейсная часть

Новой по отношению к программе является в модуле интерфейсная часть. В этой части описываются все константы, типы данных и переменных, процедуры и функции, доступные в этом модуле для использования внешними програм-мами. Интерфейсная часть моду­ля несет всю информацию, необходимую для использования проце­дур и функций, определенных в модуле. Любая другая информация о модуле для обычного его использования не нужна.

Примечание:

В рамках ИИО ТП поставляются следующие стандартные модули System, Strings, Crt, Printer, dos, WiaDos, Graph, Overlay, ОгарЬЗи Тш-ЬоЗ.

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

Следом за оператором USES в интерфейсной части описывают­ся доступные извне и необходимые для описанных процедур и функций определения типов данных, констант и переменных.

Все процедуры и функции, доступные для общего пользования и опреде-ленные в данном модуле, должны быть описаны в интер­фейсной части своей строкой-заголовком с указанием типов пара­метров. Сам текст программы этих процедур и функций находится (с дубликатом их заголовка) в реализационной части.

Нет необходимости упоминать в интерфейсной части все проце­дуры и функ-ции, используемые в реализационной части. На практи­ке возможна ситуация, когда интерфейсная часть вообще ничего не содержит, как показано в примере Unitlab.pas,, содержащем модуль Demo_unit3 . Этот модуль, конечно, лишен смысловой нагрузки, но по форме вполне корректен и работоспособен.

UNIT Demo_unit3; { Unitlab.pas}

INTERFACE {Эта часть пуста.}

IMPLEMENTATION

USES

Crt ;

BEGIN

ClrScr ;

END.

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

2.3 Реализационная часть

Реализационная часть — это часть, в которой определяются процедуры и функции. Точно так же, как и внутри обычной программы, Вы можете определить здесь глобальные (для модуля) переменные, типы данных и константы наряду с определением процедур и функций. Определенные здесь типы данных и структу­ры данных недоступны извне и могут использоваться для своих нужд только программами, входящими в реализационную часть.

Так же как и интерфейсная часть, часть реализационная может быть пустой. Такую возможность используют, если необходимо определить некоторые общие для многих программ типы данных, константы и переменные. Имея такое определение в рамках неко­торого проекта, легко включить его во все программы (главную и подчиненные) с помощью оператора USES.

2.4. Инициализационная часть

Инициализационная часть представляет собой основной блок модуля. Приведенные в ней операторы выполняются первыми, т.е. они выполняются перед операторами основного блока главной программы, в которую включен данный модуль.

Вернемся к нашему Demo_units-модулю.. Он содержит в своей инициализа-ционной части операторClrScr, заключенный в функциональные скобки BEGIN ... END. Если Вы подготовите и запустите следующую программу TUTWENIG.PAS, то вначале произойдет инициализация включенного модуля Demo_units, т.е. выполнится операторClrScr, вследствие чего будет очищен экран. Затем начнет выполняться главная программа, и на экран будет выдано сообщение "Привет!!!".

PROGRAM Uses_denio_unit3; { lab2.PAS}

(Иллюстрирует правило исполнения операторов инициализационной части включенного модуля ПЕРЕД операторами, входящими в главную программу.}

USES

Demo_units;

BEGIN

WriteLn('Привет!!!');

END.

Результатом трансляции модуля является файл с тем же именем и расширением имени.TPU, который ввиду длительно­го использования заносится на диск, тогда как результат трансля­ции программы в целом (.ЕХЕ-файл) может оставаться в основ­ной памяти. При его получении проверяется правильность обращения к блокам модуля (вот для чего нужна интерфейсная часть).

Общий объем модульной программы может быть много более 64 , но каждый .TPU-файл не может превышать 64 К.

В подменю Compile, которое показано ниже:

Compile A11-F9

Make F9

Build

Destination Memory

Primary file ...

для запуска трансляции предназначаются верхние 3 пункта, однако пункт Compile требует установки значения "Disk" опции Destination (вместо "Memory") для трансляции модуля; вторым этапом проводится трансляция основной программы. Удобнее пункты Make (F9) и Build; кроме того, можно использовать непосредственно пункт Run ("выполнение") подме­ню Run или заменяющие его клавиши Ctrl+F9. Во всех 3 случаях программа и модули транслируются совместно, активным должно быть окно основной программы, либо имя файла основной программы должно быть указано в опции Primary file.

Команда Make (клавиша F9) для каждого модуля проверяет:

— существование TPU-файла; если его нет, то TPU-файл создается путем трансляции исходного текста модуля;

— соответствие TPU-файла исходному тексту модуля, куда могли быть внесены изменения; если это так, TPU-файл авто­матически создается заново;

— неизменность интерфейсного раздела модуля; еслиэтотраздел изменился, то перекомпилируются также все модули, в начале которых данный модуль указан в предложении Uses.

Если модули давно проверены и неизменны, их исходные тексты в ЭВМ не нужны — команда Make в этом случае работа­ет только с TPU-файлами, время компиляции минимально. Напротив, команда Build требует наличия исходных текстов модулей, ибо все они компилируются. Эта "перестраховка" влечет рост времени компиляции. Чтобы были понятны дальнейшие рекомендации, следует четко представить взаимодействие модулей и основной програм­мы. Изучите схему 1 (случай двух модулей М1 и М2; разделы инициализации не предусмотрены, локальные блоки в ней не отражены).В общем случае ссылки модулей на модули могут представ­лять сложную картину. В нашем примере основная программа косвенно использует модуль М2. Если бы потребовалось обращаться непосредственно в основной программе к объявле­ниям или блокам модуля М2, мы записали бы в основной программе Uses M1,M2 вместо Uses M1. Примите к сведению, что интерфейсная часть модуля M1 как бы становится началом \ описательной части основной программы, поэтому не только объявления, но и блоки модуля M1 "видны" из подблокой основной программы, где можно обращаться к ним. Однако нельзя, например, определить константу N в основной программе, а использовать в объявлении типа в модуле M1.

UNIT M2;

INTERFACE

<0бъявления, которые "видны" лишь из модуля М1>

IMPLEMENTATION

<Блоки, доступные для обращений из модуля М1>

END.

UNIT M1;

INTERFACE

USES М2;

<Объявления, которые "видны" из основной программы>

IMPLEMENTATION

<Блоки, используемые основной программой>

END.

{Основная программа}

USES M1;

<0бъявления, которые "не видны" из модулей M1 и М2>

<Блоки, недоступные для модулей M1 и М2>

<Главная операторная часть>

END.

Схема 1. Взаимодействия модулей и основной программы

Чтобы объявления типов, например структурных, были доступны всем частям программы, их следует поместить в отдель­ный модуль и его имя указать во всех предложениях Uses. Вас не должно смущать то, что какие-то программы или блоки не используют всех объявлений из его интерфейсного раздела. Хотя раздел реализации отсутствует, слово Implementation нужно записывать как границу интерфейсного раздела. Собрав вместе часто используемые блоки, вы можете оформить еще один модуль. Процесс вычленения модулей можно продолжить и далее. К этому нас могут вынудить и другие обстоятельства. Код основной программы размещается в сегменте памяти , следовательно, он не может занимать более 64 К памяти. Раздел реализации каждого модуля занимает отдельный сегмент. Большую программу вы, безусловно, сделаете блочной. Если не вкладывать большие блоки друг в друга и подчиненные блоки записывать прежде использующих их блоков, довольно просто распределить их для размещения в разные модули: выде­лив объявления в отдельный модуль, следующие за ними блоки помещаете во 2-й модуль, идущие далее по тексту — в 3-й мо­дуль и тд. При этом 2-й модуль может ссылаться лишь на 1-й, 3-й модуль может обращаться и к 1-му, и ко 2-му и т.д.;

тем самым "круговые" ссылки модулей предотвращаются. Поскольку 1-й модуль, содержащий одни объявления, ни на один модуль не ссылается, его можно (и нужно) указать в предложе­нии Uses во всех модулях, где должны действовать эти объявления.