Непейвода Н.Н., Скопин И.Н. Основания программирования

Подождите немного. Документ загружается.

8.1. ВИДЫ ПОДПРОГРАММ

365

Более того, даже для такого строгого языка как

Pascal

, стандарт кото-

рого с целью защиты от возможных ошибок запрещает использовать вызов

функции как процедуры (если

Average

— функция, оператор

Average;

был

бы некорректен), конкретные системы программирования (например,

Turbo

Pascal

) допускают такую “вольность”.

В настоящем изложении для подпрограмм обоих видов используется тер-

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

что процедура вырабатывает требующееся нам значение и используется вну-

три выражения, либо когда нужно сослаться на конкретный язык (например,

С/С++

Некоторые подпрограммы оказываются одним из первых средств, с ко-

торыми приходится сталкиваться при знакомстве с языками программирова-

ния. Это такие подпрограммы, которые предоставляются языком или систе-

мой программирования:

• стандартные подпрограммы, представленные и зафиксированные в

описании языка;

• встроенные подпрограммы, алгоритмы которых реализуются в рамках

системы программирования (в некоторых языках стандартные и встро-

енные подпрограммы не различаются);

• библиотечные подпрограммы,которые предоставляются в системе про-

граммирования дополнительно и не регламентируются языком.

Примерами стандартных подпрограмм языка

Pascal

являются функции

Succ

Pred

. К встроенным подпрограммам языка

Pascal

относятся процеду-

ры и функции работы с файлами

Read, Write,Eof

и др. В языках

С/С++

встро-

енные и стандартные подпрограммы формально не различаются. Например,

exp

воспринимается программистом как стандартная функция, но ее опре-

деление содержится (в оговоренном стандартом языка) библиотечном файле

math.h

Библиотечные подпрограммы предназначены для поддержки определен-

ных видов работ и обычно группируются в “тематические” библиотеки. При-

мером такой библиотеки может служить пакет

afxwin.h

, который содержит

действия с простейшим окном в системе

Windows

или пакет

Canvas

для про-

граммирования простейших графических изображений в окне программы,

создаваемой

Delphi

366

ГЛАВА 8. ПОДПРОГРАММЫ

Техника использования стандартных, встроенных и библиотечных под-

программ достаточно очевидна: в их (внешнем) описании, как правило, ука-

зывается назначение продпрограмм и способы их вызова для исполнения.

Вызов процедуры для исполнения (использование процедуры) и описание

процедуры (задание в языке совокупности действий, обозначаемых процеду-

рой и активизируемых (выполняемых) при ее вызове) — два центральных

понятия, связанных с процедурой.

Библиотеки

С/С++

— это совокупность различных описаний (в том чи-

сле и описаний функций), для использования которых нужно подключение

к программе соответствующих заголовочных файлов (оператор

#include

). В

языке

С++

появилась возможность некоторых действий с пространствами

имен программы и библиотечных файлов. Включив стандартную библиоте-

ку внутрь описания

namespace <Имя>{...};

мы обеспечиваем доступ к описаниям из данной библиотеки, использовав

оператор

using <Имя>;

Эти два средства работы с библиотеками

C++

поддерживают модуляриза-

цию, хотя и очень ограниченно. В системе

Delphi

модуляризация продумана

и реализована намного лучше: в частности, при описании модуля в качестве

библиотеки для внешнего использования программист имеет возможность

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

ствия следует выполнить при активизации библиотеки и при завершении ра-

боты с ней.

Понятие подпрограммы-модуля (или просто модуля) в простейшем слу-

чае может пониматься как совокупность совместно используемых описаний.

Только этот аспект модулей заложен в понятие бибилиотечных файлов

. В

более развитых системах модульности центральной задачей является выде-

ление таких программных единиц, которые допускают независимые разра-

ботку, модификацию и использование. Таким образом, в модуле появляется

открытая часть, обычно называемая интерфейсом.

Определение 8.1.1. Интерфейс программного фрагмента — совокупность

описаний из его локального контекста,которые предоставляются другим фраг-

ментам программы, использующим данный, и, соответственно, входят в их

глобальный контекст. Реализация программного фрагмента — совокупность

описаний из его локального контекста, которые остаются недоступными для

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

8.1. ВИДЫ ПОДПРОГРАММ

367

Конец определения 8.1.1.

В модулях различаются части локального контекста, которые образуют ин-

терфейс модуля и его реализацию. В модулях языка

Object Pascal

явно выде-

ляются части

interface

implementation

. В первой лежат лишь описания, а

во второй — конкретные реализации.

Библиотеки языка

развитых средств модульности не содержат. Но в

объектно-ориентированных языках

С++

Java

Object Pascal

(часто называ-

емый

Delphi

) есть понятие класса, которое в одном из своих аспектов можно

рассматривать как комплект данных и процедур (методов), связанных с эти-

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

ризации, достаточный для применения современных технологий программи-

рования.

В описании класса языка

C++

ObjectPascal

или

Java

то,что не полагается

видеть другим,объявляется как

private

,а то,что другим полагается видеть —

public

Пример 8.1.2. Класс на языке

С++

, представляющий частный вид техниче-

ской системы — систему управления температурой жидкости.

Программа 8.1.1

class CHeatSystem : public CTechSystem;

{

Interface:

public:

CHeatsystem(){...}

System Data

struct Temperature;

int GetTemperature(Temperature* x)

{

return x->outcoming_liquid;

}

Implementation

protected:

typedef struct

{

int working_area,

368

ГЛАВА 8. ПОДПРОГРАММЫ

input_stream, outcoming_liquid;

} Temperature;

...

};

Здесь

Temperature

не дана пользователю данного класса как полностью из-

вестная ему структура, и он не знает внутреннего строения

Temperature

, ко-

торое может быть в любую секунду заменено без вреда для использующих

программ. Программист, использующий модуль, может даже не подозревать,

что на самом деле тип

Temperature

хранит не только температуру на выхо-

де системы, которая ему нужна, но и другие логически связанные с ней ха-

рактеристики, используемые внутренними процедурами моделирования или

управления.

Конец примера 8.1.2.

Несколько слов об употреблении терминов. Понятие ‘подпрограмма-модуль’

носит абстрактный характер: оно не связано ни с конкретным языком, ни

с какой-либо системой программирования или же операционной системой.

Если говорят о некотором языке, то для его средств модуляризации, есте-

ственно, используют термины этого языка. Например, когда требуется ука-

зать на подпрограмму-модуль конкретного языка, делается явное уточнение:

библиотека, библиотечный файл

и т. д. Однако термин ‘библиотека’ также

обозначает различное содержание. К примеру, как мы уже имели возмож-

ность убедиться (см. п. 1.1.2), в любой реализации языка

С/С++

представле-

но по крайней мере три вида библиотек (если смотреть со стороны системы

программирования).

Если взглянуть со стороны операционной системы, то окажется, что при-

нято различать библиотеки по их отношению к процессу загрузки программ.

Появляется два вида библиотек:статически загружаемые (

SLL

—staticlinked

library) и динамически загружаемые (

DLL

— dynamic linked library). Не будет

большой ошибкой считать, что

SLL

транслируются вместе с основной про-

граммой и являются частью ее объектного кода (неточность здесь в том, что,

конечно же, эти библиотеки хранятся в почти до конца оттранслированном

виде, готовом к подключению на самой последней стадии работы транслято-

ра и загрузчика). Что касается

DLL

, то эти библиотеки отстоят от трансляции

языка программирования еще дальше: когда потребность в соответствующих

средствах выясняется в динамике выполнения программы, операционная си-

стема обращается к хранилищу

DLL

, извлекает из него нужную подпрограм-

му-модуль, приводит ее к виду, в котором программы библиотеки могут быть

8.1. ВИДЫ ПОДПРОГРАММ

369

выполнены (выделяет память, настраивает адреса и т. д.), и тем самым дела-

ет

DLL

частью выполняемой программы. Еще один шаг в том же направле-

нии делают системы клиент-сервер (в частности, системы

CORBA

BENTO

COM

и их развития). Когда подпрограмме-клиенту требуются функции под-

программы-сервера, она устанавливает связь с сервером, который может на-

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

Сервер возвращает программе результаты, а также может модифицировать

предоставленные данные.

Иллюстрацией модульности может служить совокупность средств, опре-

деляющих регламент работы с некоторой структурой данных, например,дис-

циплину очереди, которая характеризуется следующими правилами:

1. элементы помещаются в очередь для хранения,они появляются по мере

необходимости, определяемой использующей программой;

2. для обработки элемента очереди он извлекается из нее и после этого

становится недоступным;

3. из очереди элементы извлекаются строго в порядке их поступления в

очередь; очередь может быть в трех состояниях: пустая, когда извле-

чение элемента невозможно, заполненная, когда нельзя поместить эле-

мент в очередь,и нормальная, когда возможно как пополнение очереди,

так и извлечение из нее элемента.

Для работы с очередями целесообразно подготовить комплект процедур и

функций с тем, чтобы их можно было использовать, не заботясь о деталях

реализации доступа к элементам и помещения их в очередь. Состав такого

комплекта может быть следующим:

1. функция, вырабатывающая значение состояния очереди: пустая, запол-

ненная и нормальная, в зависимости от наличия сохраняемых элемен-

тов;

2. функция, вырабатывающая значение элемента очереди и извлекающая

элемент из очереди;

3. процедура, помещающая элемент в очередь для хранения.

Для использования очереди достаточно перечисленных средств оперирова-

ния; необходимо иметь сведения о том, что происходит при их употребле-

нии, и нет никакой потребности знать, как конкретно представлена очередь

в реализации.

370

ГЛАВА 8. ПОДПРОГРАММЫ

Если теперь обратиться к реализации безотносительно к тому, как перечи-

сленные программные единицы используются, то легко заметить, что сред-

ства комплекта взаимосвязаны.Их должны объединять представляющие оче-

редь структуры данных, например, массив-хранилище элементов и два ука-

зателя: один на начало очереди, т. е. на первый из имеющихся в ней элемент,

другой на конец, т. е. на последний элемент. В свое время мы разовьем этот

пример до программной реализации и покажем, как можно использовать об-

суждаемый модуль.

Понятие подпрограммы-модуля требует развития понятия контекста. Кро-

ме локального и глобального контекста отдельного фрагмента появляются

дополнительно:

Определение 8.1.3. Общий контекст модуля —совокупность данных и дру-

гих программных единиц, описанных в модуле для совместного использова-

ния процедурами модуля, включая и сами процедуры модуля. Предоставля-

емый контекст модуля — часть средств общего контекста модуля, разрешен-

ная для использования программами, применяющими данный модуль.

Конец определения 8.1.3.

По отношению к подпрограмме-модулю общий контекст является локаль-

ным (в точном соответствии с приведенным ранее определением), а по отно-

шению к средствам из предоставляемого контекста он является частью

гло-

бального контекста. В языках программирования, которые проявляют осо-

бую заботу о защите данных от нерегламентированного использования, не

предусматривается употребление в модуле иных средств, кроме как из об-

щего контекста.

Продолжая обсуждение примера с очередями, следует указать, что:

• перечисленные три процедуры составляют предоставляемый контекст

соответствующего модуля;

• эти программные единицы плюс конкретная реализация представления

очередей,например,через массив-хранилище элементов и указатели на

начало и на конец очереди — общий контекст модуля;

• необходимые для реализации процедур внутренние данные оказывают-

ся локальным контекстом последних.

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

8.2. ИМЕНОВАНИЕ ПРОЦЕДУР

371

Отмеченное ранее разграничение того, что делает модуль, и как он это дела-

ет, указывает на повышение уровня абстрактности при совместном описании

процедур в рамках единого модуля.

С/С++

средства модуляризации программ связываются с понятием за-

головочного (header) файла, в котором явно описывается, что предоставляет-

ся модулем (текстовым файлом), озаглавленным этим заголовочным файлом.

Все остальное является локальным для данного модуля

В стандартном языке

Pascal

средства модуляризации программ, позволя-

ющие объединять описания процедур и функций, отсутствуют. Можно ска-

зать, что язык предоставляет возможность модуляризации только на уровне

операционных единиц,т. е.он допускает лишь отдельные описания процедур

и функций. Это препятствует повышению уровня абстрактности программ,

делает невозможным осуществление контроля выполнения регламента ис-

пользования данных, имеет ряд других отрицательных следствий. Для улуч-

шения языка в данном отношении системы программирования расширяют

стандартный

Pascal

, вводя в него средства модуляризации. Что касается ис-

пользования стандартного языка

Pascal

, то он практически вышел из употре-

бления. Если же приходится его использовать, то модульность имитируется

при помощи организационных мер: выбор имен, специальное расположение

текстов программ при распечатке, комментирование. Впрочем, такого рода

моделирование — обычное дело программиста, когда нет желаемых средств

в используемом языке либо системе.

Для профессиональной разработки алгоритмов и реализации их на языке

необходимо научиться не только описывать свои подпрограммы, но и приме-

нять и перестраивать при необходимости чужие, овладеть практически все-

ми возможностями, предоставляемыми инструментальным языком в части

оперирования с процедурами.

§ 8.2. ИМЕНОВАНИЕ ПРОЦЕДУР

Одним из основных средств языка, без которого невозможно использо-

вание процедур, является именование, т. е. обозначение процедуры именем,

замещающим ее алгоритм при использовании.

Когда языки программирования были преимущественно машинными язы-

Вообще говоря, это противоречит определению в стандарте языка препроцессора, как

программы, встраивающей вместо

#include

текст включаемого файла; все становится на

свои места, когда в

С++

строго определяется понятие пространства имен

namespace

372

ГЛАВА 8. ПОДПРОГРАММЫ

ками, роль имен играли адреса входа в подпрограммы (в случае ассемблер-

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

лучающем символическое обозначение). По мере устранения из языков ма-

шинных зависимостей имя подпрограммы получает самостоятельность, оно

становится обозначением алгоритма. Упоминание имени, как правило, вызы-

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

дуры позволяет при описании процедуры не заботиться о том, как она будет

использоваться, а при использовании — не знать, как реализован обозначае-

мый именем алгоритм. Таким образом, именование процедур — это одно из

средств, позволяющее при описании алгоритма сосредоточить внимание на

том, как реализовать то, что требуется в данной конкретной задаче и исполь-

зовать уже имеющиеся методы, не вдаваясь в их внутреннюю структуру.

В конструировании программ разделение аспектов, соответствующих во-

просам что? и как?, подобное только что проведенному, отражает весьма

важный принципа методологии работы со сложными системами, в том чи-

сле и программирования — принцип абстрагирования, который заключается

в разделении уровней.

• На уровне разработки программной единицы программист стремится

не знать о ее использовании, т. е. абстрагироваться от уровня исполь-

зования.

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

как она устроена (реализована), т. е. рассматривать ее как неделимое

целое, абстрактно.

Если какое-либо средство языка ориентировано на то, чтобы облегчить про-

граммисту разделение уровней, то оно поддерживает следование принципу

абстрагирования при конструировании программ. В этом отношении имено-

вание — одно из многих средств поддержки принципа абстрагирования. С

другими такими средствами мы встретимся в дальнейшем.

Применительно к языку

С/С++

именование задается заголовком функции,

в котором обязательно присутствует имя, идентифицирующее функцию:

void MyProc (Matrix M, const int SizeM)

int MyFunc ()

void PrintMatr (Matrix M, const int SizeM)

void main()

Здесь

MyProc, MyFunc, PrintMatr

main

— имена функций. Если хочется

определить процедуру, то в заголовке указывается спецификатор

void

, ука-

8.2. ИМЕНОВАНИЕ ПРОЦЕДУР

373

зывающий на то, что данная операционная подпрограмма не вырабатывает

значение.

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

дом за заголовком в виде заключаемой в операторные скобки { и } последо-

вательности операторов. Эта часть процедуры называется ее телом:

int MyFunc ()

{ //

... //

Тело процедуры

} //

Содержательно, тело процедуры — это описание алгоритма, выполнение

которого активизируется при вызове процедуры.

При абстрактно-синтаксическом представлении описания процедур не-

обходимо решить вопрос согласования такого представления с конструкци-

ей вызова процедуры. Необходимо, чтобы абстрактный вычислитель, обра-

батывая описание процедуры, обеспечил связь вызова с описанием, чтобы

при обработки вызова процедуры осуществлялся переход к телу, которое ис-

пользуется как оператор замещающий оператор вызова.В рамках этой задачи

именованию отводится следующая роль: нужно построить связь между име-

нем процедуры и ее телом. Если говорить о процедурах, не вырабатываю-

щих значения и не имеющих параметров, то содержательно задача сводится

к образованию абстрактно-синтаксической конструкции, представленной на

рис. 8.1. Этой конструкцией устанавливается атрибут <

тело

>, который мож-

но трактовать как адрес абстрактно-синтаксического представления дерева

процедуры. <

Тело

> может быть вычислено в позиции оператора, это обеспе-

чивает возможность выполнения конструкции вызова как выполнения тела.

При вызове процедуры абстрактный вычислитель, действующий в соот-

ветствии с любым из двух алгоритмов вычисления структуры конструкции

вызова (см. рис. 2.10. из § 2.3.4), прежде всего должен найти имя вызывае-

мой процедуры. Если имя не найдено, то это квалифицируется как ошибка

конструкции вызова.

Зададимся вопросом о том,где могут (или должны)храниться имена, что-

бы обеспечить возможность их эффективного нахождения? Согласно семан-

тике описания процедуры, как и любого другого описания, все имена рассма-

триваются в качестве атрибутов конструкций, в которых они появляются. В

соответствии с этим можно организовать и хранение описываемых имен как

374

ГЛАВА 8. ПОДПРОГРАММЫ

…

Оператор

Тело

процедуры

Атрибут

тело

Имя

* процедуры */ /

Рис. 8.1. Простейший случай результата обработки абстрактным вычислите-

лем описания процедуры

атрибутов соответствующих вершин дерева. Однако это не очень удобно по

следующим причинам:

• хранение и поиск имен отделены от работы с деревом абстрактного

синтаксиса, для которой требуется лишь две интерфейсные процеду-

ры: предоставить нужный атрибут имени при обращении к его исполь-

зующему вхождению и сохранить имя с его атрибутами при обработке

описания;

• обеспечение работы со стеком контекстов (см. § 7.4.2) естественно ор-

ганизовывать при обработке описаний, когда есть возможность сгруп-

пировать секции контекстов без дополнительных просмотров дерева;

• для внешних по отношению к программе сущностей указать конструк-

ции,в которых появляются их описания,затруднительно (принятое имен-

но с этой целью в

Алголе 68

соглашение о стандартном вступлении пло-

хо согласуется, например, с потребностью модульной структуры би-

блиотек).