Т. Пратт, М. Зелковиц - Языки программирования - разработка и реализация (4-е издание_ 2002) (1160801), страница 121
Текст из файла (страница 121)
Связь с общими блоками в подпрограммах Иипорт Х и Х иэ поппротраииы Р Другие объявления В операторах поено ссыпатъся на Х и Л Совместное использование определяемых явно переменных Другая форма явного определения совместно используемых объектов данных позволяет слелать объект ланцых в локальной среле какой-либо подпрограммы видимым лля других подпрограмм. Так, вместо создания группы переменных в общей среде, отлеленной от любой подпрограммы, мы используем тот факт, что кажная переменная имеет своего «владельц໠— подпрограмму, в которой она объявляется.
Чтобы сделать эту локальттут(> переменную видимой вне определения «влалетотцей» ею подпрограмиты, следует запать явное определеттие ее зкспорта, полобное объявлегпио йе("'тпев в следующем коде: ргосебыге Р(.. берн пея Х. у. Я( Х. у и Л становятся доступнычи для экспорта Х, У, 7 геа(. Обычные объявления для Х. У и 2 О. Ч эпгедег; другие локальные переиечные Ьедтп епб, Операторы Если какой-либо другой подпрограмме требуется получить доступ к зкспортированной перемепцой, то в ней используется явное определенгхе галтпорта для импортирования переменной ((тат(ример, включением объявления наев, где указаны и имя зкспортпровапной переменной, и имя подпрограммы, откуда оиа зкслортирована): ргосебыге О(.. ыяев Р.Х, Р.Х, у; тптедег( Ьедтп.
.епб 9.4. Явно определяемая общая среда 439 Описанная модель ишкзльзуется в языке С, где в объявлении переменных может задаваться модификатор ехсегп. Реализация. Эффект от такого способа совместного использования переменных мало чем отличается от использования переменных в общей среде. Экспортированная локальная переменная должна оставаться в памяти в промежутках между активациями подпрограммы, в которой она была определена. Поэтому обычно она хранится в сегменте кода этой подпрограммы, как обычная локальная сохраняемая переменная.
При ссылке на такую переменную из другой подпрограммы, которая ее импортирует, используется базовьш адрес сегмента кода экспортирующей подпрограммы и к нему добавляется соответствующее смещение. 9.4.1. Динамическая область видимости Альтернативой использованию явно определяемых общих сред для совместно используемых данных является ассоциация нелокальной среды с каждой выполняющейся подпрограммой. Нелокальная среда для подпрограммы Р состоит из множества локальных сред активаций других подпрограмм, которые становятся доступными для Р во время ее выполнения. Если в Р имеется ссылка на переменную Х, для которой нет локальной ассоциации, тогда для определения ассоциации для Х используется среда нелокальных ссылок.
Что представляет собой нслокальная среда для Р? В блочно-структурированном языке правила статической области видимости определяют неявную нелокальную среду для каждой подпрограммы. Этот довольно сложный способ рассматривается в следующем разделе. Более простой, но менее распространенной альтернативой является использование сред локальных ссылок для подпрограмм в текущей динамической цепи, которую мы и рассмотрим в данном разделе. Предположим, что в некотором языке программирования среда локальных ссылок разрушается по окончании работы подпрограммы, а определения подпрограмм не могут быть вложенными друг в друга.
Каждая подпрограмма, таким образом, определена отдельно от других. В этом случае, характерном для языков Е1БР, АРЕ и огчОВОГА, не существует статической структуры программы, на которой основываютсяя правила области видимости для разрешения ссылок па нелокальные идентификаторы. Гели, например, подпрограмма Р содержит ссылку на имя Х и Х локально нс определено в Р, то какое из определений Х в других подпрограммах следует использовать? Гстсствепный ответ закл|о <ается в том, что нужно рассмотреть динамическую цепь активаций подпрограмм, которая приводит к активации Р. Рассмотрим процесс выполнения программы: предположим, что главная программа вызывает подпрограмму А, которая вызывает В, которая, в свою очередь, вызывает Р. Если в Р имеется ссылка на Х, по отсутствует ассоциация для этой переменной, то естественно было бы обратиться к подпрограмме В, вызвавшей Р, и посмотреть, пет ли в ней ассоциации для Х.
Гслн такая ассоциация имеется, то она и используется в подпрограмме Р. В противном случае мы обращаемся к подпрограмме А, вызвавшей В, и проверяем, имеется ли в А ассоциация для Х. Мы использовали последнюю из созданных ассоциаций для Х в динамической цени вызовов подпрограмм, приводящей к Р. Такое определение значения нелокальной ссылки называется правилом 440 Глава 9. Управление подпрограммами последней ассоциации; это -- правило определения ссылки, основанное на линамической области видимости. Если среда нелокальных ссылок определена с помощью правила последней ассоциации, никаких правил статической области видимости нс используется (то есть во время трансляции программы не предпринимается никаких действий для поиска определения, ассоциированного со ссылкой на какой-либо идентификатор, для которого отсутствует локальное определение). Во время выполнения программы, когда объект данных с именем Х создается как часть активации подпрограммы Р, динамической областью видимости ассоциации для Х становятся все активации подпрограмм, вызванных из подпрограммы Р или из этих вызванных подпрограмм и т.
д. Имя Х видимо в этой динамической области видимости (за исключением активаций, где опо скрыто более поздней подпрограммой, которая имеет свосо собственнук> ассоциацию для Х). Если взглянуть на эту ситуацию с другой стороны, то нелокальпая среда активации подпрограммы Р состоит из всей динамической цепи активаций подпрограмм, приводящей к подпрограмме Р. Причнняннцпм наибольшее беспокойство свойством такой пелокальной среды является то, что она может измениться между активациями подпрограммы Р. Так, для одной активации Р, когда создается нелокальная ссылка на Х, может оказаться, что самая последняя в цепи вызовов подпрограмм ассоциация лля Х представляет его как имя массива. Для второй активации Р, реализованной через другую последовательность предшествусоших вызовов подпрограмм, динамическая цепь может изл~епиться, так что в салсой последней ассоциации для Х этому имени булст соотвс тствовать строка символов.
Для третьей активации Р может вообще не оказаться ассоциапии для Х в вызывающей пепи, так что ссьшка на Х окажется ошибкой. Эта изменчивостьь ассоциации для Х означает, что требуется применять динамическую проверку типов. Поэтому этот метод используется только в языках, подобных ЫЪР, АРЕ и ЬМОВО!Л, где динамическая проверка типов используется по другим причинам. Реализация. Реализация правила последней ассоциации для пелокальпых ссылок не вызывает затрулненнй, если для хранения записей активаций использовать центральный стек. Среда локальных ссылок для каждой подпрограммы представляется как часть ее записи активации.
Прн входе в подпрограмму создается запись активации, при выходе из нее запись активации уничтожается. Предположим, что подпрограмма Р вызывает подпрограмму 9, которая, в свою очередь, вызывает Р. Когда выполняется подпрограмма В, центральный стек может выглядеть примерно так, как изображено на рис. 9.10. Для разрешения нелокальной ссылки на Х просматривается стек, начиная с локальной среды для подпрогрсслсмы Р, в обратном направлении «е1юз всс ассоциспссси, находящиеся в стеке, пока не будет обнаружена самая последняя созданная ассоциация для Х.
Как показано на рисунке, некоторые ассоциации в стеке будут скрыты более поздними ассоциациями для того же самого идентификатора. Однако цена такой реализации правила последней ассопиации довольно высока. Поиск, необходимый для разрешения каждой нелокшсьпой ссылки, требует времени н снова приводит к необходимости хранения некоторого представления идпиписрикаторов в таблицах локальных ассоциаций, так как в каждой локальной таблице позиция ассоциации для Х может быть различной. Таким образом, нельзя применить формулу «базовый адрес + смещениеь для разрешения пелокальной ссылки. 9.4. Явно определяемая общая среда 441 Центральный стек локальная среда главной программы Заштрихованы те ассоциации, на которые нельзя ссылаться в й Среда для Р Среда для С> На в, Ц их можно ссылаться в й не локально Среда для и Рис. 9.
» О. Яктивная среда ссылок во время выполнения программы Как можно избежать процедуры поиска в разрешении ислокальиых ссылок? Бозл>ожси компромисс между ценой разрешения не локальных ссылок и ценой вхола и выхола из подпрограммы, который может оказаться выгодным, сели предположить, что разрешение иелокальиых ссылок происходит значительно чаще, чем вхол и выхол из и»>сирогрг>к>м (то сеть если нслокалы >ая среда булст игцользоваться чаще, чем о>ш модифицируется). Альтери спивная реализация использует цснтральиу>о таблицу, общу>о для всех подпрограмм, — цектралысу>о таблицу грейвс ссьи>ок. Структура цен гральиой таблицы такова, по во время выполнения нрог1>амиы в ней соЛсржатся все актитиыв на данный мол>е>сгг> ассоциации идеитификатороп исзавн гимн от того, являю» ся они локальными или иелокальнымн.
Если мы для простоты нрсдиоложилс, что множество идентификаторов, ссылки ца которые имен>тся хотя бы в одной подпрограмме, может быть определено во время трансляции, тогла ири инициализации центральной таблицы в исй солср>китгя ио одной записи лля кажлого идентификатора, независимо о> количества различных подпрограмм, в которых гает идентификатор появляется.
Каждая запись в таблице также содержит флажок активности, который указывает, имеется ли в данный момент Лля конкретной> и>сеигификатора активная ассоциация и, кроме того, отвалено ли я записи место Лля указателя иа обьскт ассоциации. Процслура разрешения всех ссылок в подпрограммах обращается к этой центральной таблице, используя схему базсшый адрес е смешение», описанную выше. Поскольку текущая ассоциация лля идентификатора х всегда расположена в олном и том же месте в центральной таблице независимо от подпрограммы, в которой появилась гсылка на этот идентификатор, и независимо от тсн о, является ли ссылка локальной или нелокщи ной, то можно применять такое простое вычисле- 442 Глава 9.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
