Текст книги "Песни о Паскале (СИ)"

Автор книги: Олег Деревенец

сообщить о нарушении

Текущая страница: 24 (всего у книги 29 страниц)

E -> F D

F -> G A

D -> C

G -> I H

A -> B

C ->

I ->

H ->

B –>

Эти строки напечатаны операторами трассировки в процедуре Expand. Согласно первой строке из узла «E» мы попадаем в узлы «F» и «D». Согласно второй – из узла «F» движемся в узлы «G» и «A», и так далее. Последние четыре строки показывают, что узлы «C», «I», «H» и «B» оказались на окраинах империи, и продвижений оттуда нет. По этой трассировке нетрудно нарисовать дерево воображаемого продвижения купцов (рис. 145).

Рис.145 – Воображаемое продвижение купцов

Сопоставьте это дерево с тем, что нацарапал на песке придворный программист (рис. 144). Разницы не заметит только слепой. В чем дело? Неужели вкралась ошибка?

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

Аты-баты

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

Для постройки кратчайшего пути надо указать узел, из которого мы хотим попасть в центр империи. Двигаясь из него по цепочке обратных ссылок в направлении центра, мы, в конце концов, попадем в него. Значение обратной ссылки в центре империи равно NIL, что будет признаком окончания пути. С этой работой справится несложная функция MakePath – «создать путь».

function MakePath(arg : PNode): string;

В функцию передается узел, от которого надо вернуться к корню дерева, то есть к центру империи. Результатом будет строка пути вида «A –> B –> C».

Главную программу слегка дополним. Теперь пользователь введет названия двух стран, между которыми ищется кратчайший путь: «откуда» и «куда». Страну «откуда» назначим центром империи, а из страны «куда» будем возвращаться по цепочке обратных ссылок, – она составит параметр функции MakePath. Поскольку вводятся названия стран, а не указатели на них, преобразование имен в указатели тоже сделаем в главной программе.

Итак, в главной программе выполняются:

• ввод графа из текстового файла;

• ввод имен двух стран и преобразование их в указатели;

• подготовка узлов графа – заполнение полей начальными значениями;

• обход графа в ширину из заданного корня;

• распечатка кратчайшего пути по цепочке обратных ссылок.

Все действия, кроме первого, зациклим, – тогда пользователь сможет задавать для этого графа разные сочетания стран. Признаком выхода из цикла будет ввод любого символа, отличного от латинской буквы. Надеюсь, что сказанного достаточно, чтобы разобраться в программе «P_58_2». Эта программа включает части программ «P_57_1» и «P_58_1», которые я лишь обозначил.

{ P_58_2 – Поиск кратчайшего пути и определение расстояний в графе }

type { Описания типов взять из P_58_1 }

var List : PNode; { список всех стран континента }

Que : PLink; { очередь присоединяемых узлов }

      { Функция поиска страны (узла графа) по имени страны }

function GetPtr(aName : char): PNode;

{ Взять из P_57_1 }

end;

      { Функция создает новую страну (узел) }

function MakeNode(aName : Char): PNode;

{ Взять из P_57_1 }

end;

      { Процедура установки связи узла p1 с узлом p2 }

procedure Link(p1, p2 : PNode);

{ Взять из P_57_1 }

end;

      { Процедура чтения графа из текстового файла }

procedure ReadData(var F: Text);

{ Взять из P_57_1 }

end;

      { Помещение указателя на узел в глобальную очередь Que }

procedure PutInQue(arg: PNode);

{ Взять из P_58_1 }

end;

      { Извлечение из очереди указателя на узел }

function GetFromQue(var arg: Pnode): boolean;

{ Взять из P_58_1 }

end;

      { Инициализация списка узлов перед "постройкой империи" }

procedure InitList;

{ Взять из P_58_1 }

end;

{ Процедура расширения (экспансии) "империи", начиная с заданного узла arg }

procedure Expand(arg : PNode);

{ Взять из P_58_1,

выделенные там операторы для трассировочной распечатки удалить }

end;

      { Функция для формирования пути от центра империи к заданному узлу }

function MakePath(arg : PNode): string;

var p : PNode;

S : string;

begin

S:= arg^.mName;       { имя конечного узла }

p:= arg^.mPrev;       { указатель на предыдущий узел }

while Assigned(p) do begin       { пока не достигли корня }

S:= p^.mName +' -> '+ S;       { добавляем к пути имя узла }

p:= p^.mPrev;       { переход к следующему узлу }

end;

MakePath:= S;

end;

var F_In {, F_Out} : Text; { входной и выходной файла }

      C1, C2 : Char;       { названия стран "откуда" и "куда" }

      Start, Stop : PNode; { узлы "откуда" и "куда" }

begin {– Главная программа –}

{ Инициализация списка узлов и очереди узлов }

List:= nil; Que:= nil;

Assign(F_In, 'P_57_1.in');

ReadData(F_In);       { чтение графа }

{ Цикл ввода названий стран }

repeat

Write('Откуда= '); Readln(C1);

C1:= UpCase(C1);

if not (C1 in ['A'..'Z']) then break;

Write('Куда = '); Readln(C2);

C2:= UpCase(C2);

if not (C2 in ['A'..'Z']) then break;

Start:= GetPtr(C1);       { начальный узел }

Stop:= GetPtr(C2);       { конечный узел }

if Assigned(Start) and Assigned(Stop) then begin

{ если такие страны существуют, }

      InitList;       { устанавливаем начальные значения в полях узлов }

      Expand(Start); { расширяем "империю" от узла Start }

      Writeln (Stop^.mDist:3, ’’:3, MakePath(Stop));

end;

until false

end.

И вот настал час испытаний, вводим данные и получаем это:

Откуда: E

Куда:       H

3 E -> F -> G -> H

Ура! Заработало! Сколько труда за этой короткой строчкой! Оправданы ли наши усилия? Конечно! Истина дорого даётся, но теперь мы не заблудимся даже в многотысячном графе!

Графы – это мощный инструмент для решения широкого круга инженерных задач. Их применяют при сортировке и поиске данных (здесь используют деревья), в расчетах электрических схем и потоков жидкостей, – всё не перечислить. Мы отщипнули лишь краешек этого каравая, вы можете узнать о графах больше по книгам [9] и [17] из списка рекомендуемой литературы.

Итоги

• Обход графа в ширину – это один из базовых алгоритмов обработки графов. На нём основано решение многих задач, в том числе – поиск кратчайшего пути между узлами.

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

А слабо?

А) Изобразите граф, содержащий не менее 20 вершин, обозначьте вершины латинскими буквами и поищите в этом графе кратчайшие пути программой «P_58_2».

Б) Пусть узлы графа – это города, а ребра – дороги между ними. Расстояния между городами разные и они известны. Как отразить в структуре графа эти расстояния? Предложите что-нибудь.

В) Пусть расстояния между городами указаны в поле mDist записи TLink.

      TLink = record       { Тип список связей }

      mLink : PNode; { указатель на смежный узел }

      mDist : integer; { расстояние между городами }

      mNext : PLink; { указатель на следующую запись в списке }

      end;

Предложите формат входного файла, содержащего в числе прочего расстояния между городами.

Г) Пусть выбран следующий формат входного файла, содержащий расстояния между городами (приведена одна строка).

A C 20 E 40

Здесь первый символ, как и ранее, обозначает текущий узел. Затем перечисляются его соседи с указанием расстояний до них. Например, между узлами «A» и «C» 20 км, а между узлами «A» и «E» – 40 км. Напишите процедуру ввода графа из такого файла.

Д) Напишите программу для поиска кратчайшего пути с учетом расстояний между городами. Подсказка: измените процедуру обхода в ширину так, чтобы серый кандидат исследовал всех соседей (не только белых), проверяя в них поле расстояния mDist. Если путь к соседу через кандидата окажется короче того, что уже отмечен в соседе, то следует изменить как расстояние, так и обратную ссылку в соседе. Вдобавок если сосед не серый, он ставится в очередь.

Е) Предположим, что купцам интересны не расстояния между столицами, а размер пошлин, вносимых при пересечении границ. Эти пошлины зависят от пересекаемой границы (то есть от пары стран). Годится ли для этого случая рассмотренная выше модель с разными расстояниями между городами?

Ж) С некоторых пор купцы учредили свой ежегодный съезд – Континентальный Купеческий Конгресс, где обсуждали свои проблемы. Каждая страна отправляла на съезд по одному делегату, а расходы на пересечение границ (визы) оплачивались из общей кассы. Посчитайте эти расходы (1 пиастр за каждое пересечение), если известна страна проведения конгресса. Учтите, что купцы следовали на съезд кратчайшими маршрутами.

З) Напишите программу для определения страны, где можно провести съезд с наименьшими издержками (см. задачу Ж).

И) Решите задачи Ж и З для случая разной стоимости виз на границах.

Глава 59

Крупные проекты

Вы заметили, насколько разбухли наши программы? Если так пойдет и дальше, то скоро вам понадобятся инструменты, применяемые в крупных проектах.

О модулях и разделении труда

Пока я возился с новой программкой, мой холодильник опустел, а на кухне скопилась немытая посуда. Впрочем, это пустяки в сравнении с заботами наших предков – крестьян, что жили сотни лет назад. Смотрите: вот мужик в окружении десятка голодных ртов, а там ещё князь с дружиной. И всех накорми, одень, согрей. А делать все самому: пахать и сеять, избу рубить, ткать, шить и лапти плести. Эта морока называлась натуральным хозяйством.

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

Взять хотя бы производство автомобиля – не самого сложного изделия по нынешним временам. А сколько народу копошится вокруг! Автомобильные заводы грандиозны, хотя здесь лишь собирают машины из частей, что делают на других заводах. Части сложных изделий называют узлами или модулями. Модуль – это часть изделия, которую можно изготовить и проверить отдельно от целого. Сборка изделий из модулей дала и высокое качество товара, и бешеную производительность труда. Так новые технологии породили и роскошные машины, и свободное время, убиваемое нами в автомобильных пробках.

Говорят, что история повторяется, ведь с технологиями программирования случилось то же самое, но гораздо быстрее. Ещё полвека назад одну программу мастерил один человек, – то была эпоха первых компьютеров и «натурального хозяйства» в программировании. По мере развития компьютеров росли и аппетиты пользователей, усложнялись решаемые задачи. Сообразно задачам усложнялись программы, и производство их в одиночку стало немыслимо. Потребовались разделение труда и специализация программистов, – точь-в-точь как в промышленности. И теперь производством сложных программ заняты программистские «фабрики».

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

Модули

Вам срочно потребовалась новая программа? Так призовите больше программистов и пусть они трудятся разом! Легко сказать, но как это сделать? Могут ли три писателя сразу сочинять один роман? Первый строчит начало, второй – середину, а третий – окончание? Или три художника писать одну картину? Но в программировании такое возможно! – выручает модульная организация программ.

В Паскале, как и в других современных языках, большой программный проект можно разбить на ряд частей – модулей (UNIT). Модули могут быть написаны и отлажены разными программистами на разных компьютерах независимо друг от друга, а затем соединены в одну программу. В этом и состоит модульное программирование.

Разделять на модули полезно даже небольшие проекты. Ведь модули – это своего рода склады, хранящие процедуры, функции и другие полезные вещи, – эти запасы пригодятся в других проектах. Модули в Паскале называют ещё библиотеками. Если так, то их содержимое – процедуры и функции – можно уподобить книгам. В поставку IDE включен ряд библиотек, содержащих массу полезных процедур, функций и типов данных. Это богатство служит для связи с операционной системой, устройствами ввода-вывода, и помогает строить красивые оконные интерфейсы. Фирменные библиотеки сделают ваши программы по-настоящему профессиональными, вам надо лишь разобраться в технологии модульного программирования.

Дробление модуля – «смертельный» номер

Рассмотрим заурядный случай. Положим, вы работаете над проектом строк эдак на пятьсот, что составляет десяток страниц печатного текста. Немалая часть вашей программы – процедуры, функции – уже отлажена, проверена и может пригодиться в других работах. Файл программы разбух, и потому работать с ним неудобно. К чему эти готовые куски маячат перед глазами и мешают рыться в проблемных частях? Зреет здравая мысль: а не вынести ли их куда-нибудь в другой файл? Но так, чтобы связь с ними, не терялась. А потом, при необходимости, воспользоваться этими кусками в других проектах. Эти разумные мысли ведут вас к модульному программированию.

Сейчас мы разобьем на модули одну из наших программ. Нужен «доброволец», пусть им будет программа «P_56_1». Мы распилим её на две части подобно тому, как фокусник распиливает артистку в цирке. Не пугайтесь, – программа, как и артистка, останется живёхонька и здоровёхонька. Напомню, что «P_56_1» – это шуточная программа для перестановки строк файла в обратном порядке. Вот её схема, где тела процедур я заменил многоточиями, а часть комментариев удалил. Для экономии места дальше я буду показывать программу схематично.

{ P_56_1 – перестановка строк файла }

type PRec = ^TRec;

      TRec = record

      mStr : string;

      mNext : PRec;

      end;

var Stack : PRec; { Голова стека }

procedure Push(const arg : string);

{... }

end;

function Pop(var arg : string): boolean;

{... }

end;

{ – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – }

var F : text; S : string;

begin       {– Главная программа –}

{... }

end.

Вероятно, средства для работы со стеком пригодятся нам где-то ещё, и есть смысл сохранить их на складе. Разделим программу на две части. Первую часть, до пунктирной линии – подпрограммы Push, Pop, объявление типа и переменную Stack – скопируем в другой файл и назовем его «MyLibr» – моя библиотека. Сохраним библиотеку в папке с нашими программами. Здесь вам пригодится умение работать с несколькими окнами и держать открытыми оба файла.

Скопированный кусок в исходной программе теперь не нужен, – выбросим его, а то, что осталось, сохраним под именем «P_59_1».

{ P_59_1 – Первичный файл проекта }

var F : text; S : string;

begin       {– Главная программа –}

{... }

end.

Файл с главной программой называют первичным (Primary), стало быть, «P_59_1» – это первичный файл нашего проекта. Будет ли он компилироваться? Ясно, что нет. Ведь там вызываются удаленные из файла процедура и функция. Надо подсказать компилятору, что они переехали в файл «MyLibr». Для такой переадресации служит список импорта, который возглавляет ключевое слово USES. Пользоваться списком импорта легко, – достаточно поместить его в начале программы, перечислив после слова USES имена нужных модулей (несколько имен разделяются запятыми). В нашем случае внешним модулем является файл «MyLibr», поэтому дополненный списком импорта первичный файл станет таким.

{ P_59_1 – Первичный файл проекта }

uses MyLibr; { импортируемый модуль }

var F : text; S : string;

begin       {– Главная программа –}

{... }

end.

Как видите, расширение файла в списке USES не указывают, а сам список завершает точка с запятой. Теперь все, что компилятор не найдет в основной программе, он будет искать в файле «MyLibr». Говорят, что первичный файл импортирует модуль «MyLibr». Компилируется такой проект из двух файлов как обычно – нажатием клавиши F9. Впрочем, для успешной компиляции время ещё не пришло.

Теперь обратимся к файлу «MyLibr». На первый взгляд он содержит всё нужное для компиляции, но это не так. Ведь это не программа, а лишь часть её – модуль. Файлу надо придать особую форму – форму библиотечного модуля, что достигается вставкой в него четырех обязательных ключевых слов (ниже они выделены).

unit MyLibr;       { имя библиотечного модуля }

interface       { секция интерфейса }

{...}

{– – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – -}

implementation { секция реализации }

{...}

end.

Обратите внимание на последнее слово END с точкой. Так же, как в главной программе, оно обязательно и завершает библиотечный модуль.

Но открывает файл ключевое слово UNIT (модуль), – оно назначает модулю имя. Имя указывают за словом UNIT через пробел, эта строка завершается точкой с запятой. Имя модуля должно совпадать с именем файла, но без расширения PAS. Впрочем, имя может быть и длиннее – до 63-х символов, но первые восемь из них должны повторять имя файла. Итак, присвойте модулю имя MyLibr.

Следующие два ключевых слова: INTERFACE (интерфейс) и IMPLEMENTATION (реализация) делят модуль на две части. Эти части так и называются: секция интерфейса и секция реализации. Важно правильно расставить эти ключевые слова. Кстати, точка с запятой за ними не ставится!

Начнем с секции реализации, хотя по порядку она идет второй. Эта секция должна вмещать всё (или почти всё), что требуется для работы модуля: объявления типов, констант, переменных, а также процедуры и функции. Иными словами, в неё сейчас свалим то, что перетащили из основной программы. Итак, слово IMPLEMENTATION мы поставим перед описанием типов, и в результате библиотечный файл станет таким.

unit MyLibr;       { имя библиотечного модуля }

interface       { секция интерфейса }

{– – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – -}

implementation { секция реализации }

type PRec = ^TRec;

      TRec = record

      mStr : string;

      mNext : PRec;

      end;

var Stack : PRec; { Голова стека }

procedure Push(const arg : string);

{... }

end;

function Pop(var arg : string): boolean;

{... }

end;

end.

Теперь обратимся к секции интерфейса. Хотя слово INTERFACE уже на месте, но секция пока пуста. Каково её назначение? Здесь пора рассказать о видимости объектов, размещенных в модуле. Точнее, о видимости их за пределами этого модуля. Оказывается, что всё, что помещено нами в секцию реализации, невидимо извне, скрыто от посторонних глаз. Так устроено по причинам, которые мы обсудим позже. Но для компиляции проекта надо приоткрыть часть модуля внешнему миру. Иначе из главной программы (которая проживает в другом файле) не будут видны нужные ей идентификаторы библиотечного модуля. Для этого и нужна секция интерфейса.

На обозрение выставим только те идентификаторы, которые нужны внешним модулям. Что именно? Как это узнать? Самый верный способ – запустить компиляцию первичного модуля, и тогда компилятор покажет первый незнакомый идентификатор, – его описание и разместим в секции интерфейса. Повторная компиляция выявит следующий неизвестный идентификатор. Так постепенно мы обнаружим, что первичный модуль нуждается в переменной Stack, процедуре Push и функции Pop. Впрочем, вам это было и так ясно.

Как выставить напоказ константы, переменные и описания типов? Надо просто напросто перенести их из секции реализации в секцию интерфейса. Но с процедурами и функциями так не выйдет. В секцию интерфейса нельзя вставлять исполняемый код – только объявления! Но можно разместить заголовки процедур и функций, для чего просто скопировать их ещё раз. Сделав это, мы получим следующий библиотечный модуль.

unit MyLibr;       { имя библиотечного модуля }

interface       { секция интерфейса }

type PRec = ^TRec;

      TRec = record

      mStr : string;

      mNext : PRec;

      end;

var Stack : PRec; { Голова стека }

procedure Push(const arg : string);       { заголовок процедуры }

function Pop(var arg : string): boolean;       { заголовок функции }

{– – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – -}

implementation { секция реализации }

procedure Push(const arg : string);

{... }

end;

function Pop(var arg : string): boolean;

{... }

end;

end.

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

Всё, что размещено в секции интерфейса, называют списком экспорта библиотечного модуля. Таким образом, первичный модуль программы импортирует то, что экспортирует библиотечный модуль, – так налаживается связь между модулями. На рис. 146 показаны окна с файлами нашего проекта: вверху – первичный файл, внизу – файл библиотечного модуля.

Рис.146 – Окна преобразованного проекта P_59_1

Компиляция проекта

Теперь все готово для компиляции и запуска нашего проекта. Перейдите в окно первичного модуля и нажмите сочетание Ctrl+F9, – оба файла будут откомпилированы, и программа запустится как обычно. Я не зря прошу перейти в окно именно первичного модуля. Если при нажатии Ctrl+F9 активным будет другое окно, компилятор выдаст обидное сообщение: «Cannot run a unit» – нельзя запустить модуль. В самом деле, модуль – это лишь часть программы, он не может быть исполнен. Компилятор же считает, что в активном окне содержится главная программа и пытается её запустить.

Чтобы не спотыкаться здесь, настройте в IDE имя первичного файла, то есть файла с главной программой, – здесь это «P_59_1». Для этого обратитесь к пункту меню Compile –> Primary file… и укажите там нужный файл (рис. 147). Теперь компилятор будет знать, с какого файла начинать компиляцию. Но и библиотечный файл «MyLibr» он тоже будет обрабатывать всякий раз, когда вы измените в нём что-то, – это очень удобно.

А если начнёте другой проект? Тогда не забудьте сменить имя первичного файла, либо сбросьте это имя через пункт меню Compile –> Clear Primary file.

Рис.147 – Пункты меню для настройки первичного файла

Инициализация модуля

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

Начнем с того, что переменная Stack упоминается в главной программе лишь однажды – при инициализации.

Stack:= nil; { Инициализация стека пустым значением }

Когда-нибудь – в будущих проектах – вы забудете об этой важной мелочи, и наживете несколько часов головной боли. Но, если эту инициализацию перенести в модуль MyLibr, то можно впредь не вспоминать о ней. Для этого создадим в модуле ещё одну секцию – секцию инициализации. Она располагается в модуле последней и открывается ключевым словом BEGIN, вставленным перед завершающим словом END. Между этими словами записывают операторы инициализации, – все это похоже на главную программу в первичном модуле. В нашем случае секция будет такой.

unit MyLibr;

{... }

begin       { секция инициализации модуля }

Stack:= nil; { Инициализация стека }

end.

Когда сработает эта инициализация? Вы знаете, что стрельба начинается с операторов главной программы в первичном модуле «P_59_1». Это справедливо, пока не подключены библиотечные модули. С ними порядок исполнения программы слегка изменится. Первыми будут выполнены операторы в секциях инициализации подключенных модулей, причем в том порядке, в каком эти модули перечислены в списке USES (если там указано несколько модулей). И лишь затем начнёт выполняться главная программа в первичном модуле. Этот порядок гарантирует компилятор, ваше вмешательство здесь не требуется.

Итак, переместив инициализацию переменной из главной программы в модуль, мы обеспечим её автоматическое выполнение и в будущих проектах. Разумеется, что в главной программе инициализация уже излишня. А раз так, то и переменная Stack с описанием её типа в секции интерфейса уже ни к чему, – вернем все это в секцию реализации. После всех перемещений наш проект обретет окончательный вид.

Внешний библиотечный модуль.

unit MyLibr;       { имя библиотечного модуля }

interface       { – секция интерфейса – }

procedure Push(const arg : string); { заголовок процедуры }

function Pop(var arg : string): boolean;       { заголовок функции }

{– – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – -}

implementation { – секция реализации – }

type PRec = ^TRec;       { Тип указатель на запись }

      TRec = record       { Тип запись для хранения связанных строк }

      mStr : string; { хранимая строка }

      mNext : PRec; { указатель на следующую запись }

      end;

var Stack : PRec; { Голова стека }

      { Процедура размещения строки в стеке }

procedure Push(const arg : string);

var p : PRec;

begin

New(p);       { создаем новую переменную-запись }

p^.mStr:= arg;       { размещаем строку }

{ размещаем в голове стека }

p^.mNext:= Stack; { указатель на предыдущую запись }

Stack:=p;       { текущая запись в голове стека }

end;

      { Процедура извлечения строки из стека }

function Pop(var arg : string): boolean;

var p : PRec;

begin

Pop:= Assigned(Stack); { Если стек не пуст, то TRUE }

{ Если стек не пуст… }

if Assigned(Stack) then begin

arg:= Stack^.mStr;       { извлекаем данные из головы стека }

p:= Stack;       { временно копируем указатель на голову }

Stack:= Stack^.mNext; { переключаем голову на следующий элемент }

Dispose(p);       { удаляем ненужный элемент }

end

end;

begin       { – секция инициализации модуля – }

Stack:= nil; { Инициализация стека пустым значением }

end.

Теперь в интерфейсной части модуля маячат лишь процедура Push и функция Pop. Первичный файл проекта с главной программой станет таким.

{ P_59_1 – Первичный файл проекта }

uses MyLibr;

var F : text; S : string;

begin       {– Главная программа –}

{ Открываем входной файл }

Assign(F, 'P_56_1.pas'); Reset(F);

{ Пока не конец файла, читаем строки и помещаем в стек }

while not Eof(F) do begin

      Readln(F, S); Push(S);

end;

Close(F);

{ Открываем выходной файл }

Assign(F, 'P_56_1.out'); Rewrite(F);

{ Пока стек не пуст, извлекаем и печатаем строки }

while Pop(S) do Writeln(F, S);

Close(F);

end.

Откомпилируйте проект, запустите и проверьте, жива ли распиленная «дамочка»?

Структура модуля

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

Прежде всего, уточним структуру модуля. Из рис. 148 следует, что она схожа со структурой программы. В состав модуля, по мере необходимости, включаются те же самые персонажи: константы, типы данных, переменные, процедуры и функции. Все это может располагаться в одной из двух секций. То, что требует экспорта, выставляют напоказ в секции интерфейса, а остальное прячут в секции реализации. Что касается процедур и функций, то в секцию интерфейса выносят при необходимости лишь копии их заголовков, а сами подпрограммы поселяют в секции реализации. Константы, типы и переменные, объявленные в секции интерфейса, в секции реализации не повторяют.

О совпадении имен

Настало время ответить на отложенный вопрос: зачем прятать часть модуля, почему бы не выставить все напоказ? На это есть две причины, и обе веские.

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

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

Но хуже, если программа скомпилируется! В этом состоит вторая причина сокрытия лишних имен. Если компилятор найдет искомое, но не в том модуле, в котором вы предполагали – то-то будет морока с отладкой!

Отсюда вывод: не выставляйте напоказ ничего лишнего, будьте скромнее, – так поступают профессионалы. И все же полностью исключить нежелательное совпадение имен удается не всегда. Как быть? Выход есть – используйте префикс с именем модуля. Префикс – это приставка перед идентификатором, отделяемая от него точкой. Например, в главной программе нашего проекта вызовы процедур можно записать так:

      MyLibr.Push(S);

      while MyLibr.Pop(S) do...

Этим мы подсказали компилятору, что процедуры Push и Pop берутся из модуля MyLibr и боле ниоткуда.

Рис.148 – Общая структура библиотечного модуля

Модуль, указанный в префиксе, должен упоминаться в списке USES. Но есть одно исключение – это модуль по имени SYSTEM. В этом библиотечном модуле собраны процедуры и функции, встроенные в Паскаль. Модуль SYSTEM в списке USES никогда не упоминают.

Иногда программисты называют свои процедуры и функции так же, как встроенные в модуль SYSTEM, – это не запрещено. И тогда для уточнения имен пользуются префиксами с именами библиотек, например:

      System.Writeln(F);       { стандартная процедура }

      MyModule.Writeln(S); { моя «самоделка» }

Завершая обзор структуры модуля, обратим внимание на необязательные списки импорта USES в секциях интерфейса и реализации (рис. 148). Через эти списки библиотечный модуль импортирует нужные ему элементы из других модулей. Составляя списки, следуйте простому правилу: если внешний модуль требуется только в секции реализации, упоминайте его в списке USES секции реализации, а иначе – в секции интерфейса. Упоминать модуль в обоих списках нельзя. А когда импортировать нечего, список импорта не вставляют.