Н. Джехани - Язык Ада (1988) (1160771), страница 104
Текст из файла (страница 104)
В случае задания тела программного модуля следом тела требуется, чтобы субмодуль, содержащий соответствующее тело, бып откомпилирован раздельно. В случае подпрограммы спецификации подпрограммы, данные в соответствующем теле и в следе тела, должны быть согласованы (см. 6.3.1). Для каждого субмодуля задается имя родительского модуля, т.е. компилируемого модуля, содержащего соответствующий след тела. Если родительский модуль — библиотечный модуль, то он называется предком. Если родительский модуль сам является субмодулем, то его имя должно быть представлено расширенным именем, начинающимся простым именем библиотечного модуля-предка. Простые имена всех субмодулей, которые имеют одинакового предка, должны задаваться различными идентификаторами.
Видимость в соответствующем теле субмодуля — это видимость, которая была бы получена в масте задания следа тела (в родительском модуле), если бы спецификаторы совместности и использования субмодуля были добавлены к спецификатору контекста родительского модуля. Если родительский модуль сам является субмодулем, то это же правило используется для определения видимости в соответствующем тепе родительского модуля. Результатом предвыпопнения следа тела является предвыполнение соответствующего тела субмодуля. Примечание. Два субмодуля различных библиотечных модулей в одной и той же программной библиотеке могут иметь совпадающие идентификаторы. В этом случае их расширен.
ные имена различны, так как различны простые имена библиотечных модулей и простые имена всех субмодупей одного предка данного библиотечного модуля. Средствами описаний пе. 819 и мы я па тат козгпяшя пп реименоаания могут быть введены для (различных) субмодулей соамащенные имена подпрограмм. Библиотечный модуль, упомянутый е спецификаторе соаместнооти субмодуля, может быть скрыт описанам (с тем же идентификатором), данным а соотаетстеующем теле субмодупя.
Более того, такой библиотечный модуль может быть скрыт описанием, данным а роди. гальском модуле, так как библиотечный модуль рассматриаается как описанный а пакете ЗТА(ЧОАНБТ зто, однако, не епияет на интерпретацию спецификатороа совместности, ибо е них могут быть упомянуты имена только библиотечных модулей. Ссылки: библиотечный модуль 10.1, видимость 8.3, задача 9, задачный модуль 9.1, идентификатор 2.3, имя 4.1, компилируемый модуль 10.1, локальное описание 8.1, настраиааемое тело 12.2, настраиваемый модуль 12, непосредстаенная видимость 8.3, непосредстаенное ахожде.
ние 8.1, описание 3.1, описаниа переименования 8.5, пакет 7, подпрограмма 6, предеыполнение 3.9, программа 10, программный модуль 6, простое имя 4.1, раздел описаний 3.9, раздельная компиляция 10.1, расширенное имя 4.1.3, скрыт описанием 8.3, соамещение 8.3, согласованный 6.3.1, соответствующее тело 3.9, спецификатор использования 8.4, спецификатор контекста 10.!.1, спецификатор совместности 10.1.1, спецификация подпрограммы 6.1, тело задачи 9.1, тело пакета 7.1, тело подпрограммы 6.1. 10.2.1. ПРИМЕРЫ СУБМОДУЛЕЙ Сначала процедура ТОР оформлена а виде компилируемого модуля без субмодулей. каЬ ТЕХТ (О; ргоаомее ТОР Ь Фуре ВЕА(.
Ь глаяв 10; Я, 3: ВЕАЬ:= 1.0; Раоьаав РАС(Ф(ТУ Ь РФ; оопшагя = 3.141БЗ 28БЗБ; Ьгкяое Р (Х: ВЕАЫ клее ЯЕАФ.; рпкадеге 6 (У. 2: ВЕАСП аео РАСФМТУ; Рвозаав Ьн(у РАСИ„(ТУ Ь вЂ” предшествуют некоторые локальные описания Ьавяое Р(Х: НЕАО карге ЯЕАФ Ь Ьер(е — последовательность операторов Функции Р рговоаеге 6(У, 2: ЯЕАО Ь вЂ” использующие пакет ТЕХТ 10 локальные процедуры Ьер(а — последовательность операторов процедуры 6 еео 6; аея РАС(ЫТУ. ркоаоеге ТНАНЗРОНМ(0: Ь огп ВЕАО Ь еве РАС(ЫТУ; Ьвр(е О: Р(0(; мга ТВАНЗРОВМ; Ьаа(п — ТОР ТЯАМЗРОНМ(й); РАООТУ.О(й, 3): вад ТОР; Тело пакета РАСТУ и процедуру ТНАЗ(ЗРОНМ можно представить а виде раздельно компилируемых субмодупей модуля ТОР.
Тело процедуры 6 также может быть предстазпено как субмодуль модуля ЕАС(МТУ. Глава 10 Пример Ер ргосоаоге ТОР !е (уре НЗАЬ Ь а(В<М (О; й, 8: ВЕАь:= 1.0; р Ьвц Р<: со мопс:= зле(за евззз: Ьпсаоп Г (Х: ЯЕАЬ! !аппп йЕА1.; ргосеапге 6 (У, Е: йЕАЬЙ епЬ ГАСИ.1ТУ; р сьмо Ь ау ЕАСИатт Ь сер ам; — след тела еАс1мту р а«тнпнвеоям(((: м огп яеА() ь свр м: — след тела тяпнзроям Ьвем — ТОР ТВАНЗЕОНМ<й): ЕАС1ШТУ.З(й, 81; впЬ ТОР; вврагага (ТОР! ргосваогв ТЯАНЗГОЙМ(0: 1п ов( ЙЕАО Ь овв ЕАС!Оту; Ьае!п 0:= Е!61: епа ТНАНЗГОЯМ; серагмв (ТОР! Раскове Ьоау ГАС<ОП Ь -- предшествуют некоторые локальные описания Ъпс!Ьо Г(Х: ЯЕАЦ пппгп ЯЕАЬ 1 ° Ьве!и -- последовательность операторов функции Е впа Е: ргосвЬогв 6(У, 2: НЕАО Ь оврага!о; а ГАс<мту; — след тела 6 гснЬ ТЕХТ (О; ° врага!е (ТОР.ЕАС!ОТУ! ргосеапге 6<У.
Е: НЕАО Ь вЂ” использующие ТЕХТ 10 локальные процедуры — полное имя пакета ГАС!Оту Ьее(п — последовательность операторов процедуры 6 В этом примере ТЙАНЗЕОЙМ и ЕАСЫТУ являются субмодулями процедуры ТОР, а 6— субмодулем пакета ЕАСЫТУ. Видимость в этом примере такая же, как и в предыдущем, с одним отличием; ТЕХТ (О используется только в 6, поэтому соответствующий спецификатор совместности написан для 6, а не для процедуры ТОР. В остальном видимость идентификаторов в соответствующих телах программ обеих версий одинакова.
Например, в соответствую. щем тепе субмодуля 6 (непосредственно) видимы процедура ТОР, тип ЯЕА(, переменные я и 3, пакет ЕАС<МТУ и содержащиеся в нем именованное число Р( и подпрограммы Е и 6. Ст л шшы н льтат комплля и» 421 Ссылки: видимость 8.3, идентификатор 2.3, именованное число 3.2, компилируемый модуль 10.1, локальное описание 8.1, пакет 7.1, переменная 3.2.1, подпрограмма 6, процедура 6, след тела 10.2, соответствующее тело 3.9, спвцификатор совместности 10.1.1, тело пакета 7.1, тело процедуры 6.3, тип 3.3.
10.3. ПОРЯДОК КОМПИЛЯЦИИ Правила, определяющие порядок компилирования модулей, являются непосредственным следствием правил видимости и, в частности, того факта, что любой библиотечный модуль, упомянутый в спецификаторе контекста компилируемого модуля, видим в нем. Компилируемый модуль должен компилироваться после всех библиотечных модулей, указанных в его сгацификаторе контекста. Вторичный модуль, являющийся телом подпрограммы или пакета, должен компилироваться после соответствующего библиотечного модуля. Любой субмодуль родительского компилируемого модуля должен компилироваться после него. Компилирование, при котором в компилируемом модуле обнаружена ошибка, считается неудавшимся и никак не влияет на программную библиотеку; то же самое относится и к перекомпиляции (никакой компилируемый модуль не может стать устаревшим вследствие такой перекомпиляции].
Порядок компилирования компилируемых модулей программы должен отвечать части+ ной упорядоченности, определенной приведенными выше правилами. Аналогичные правила применяются при перекомпиляции. На компилируемый модуль потенциально влияет изменение любого библиотечного модуля, упомянутого в его спецификаторе контекста. На вторичный модуль потенциально влияет изменение соответствующего библиотечного модуля. На субмодупь потенциально влияет изменение родительского компилируемого модуля.
В результате успешной перекомпиляции компилируемого модуля все компилируемые модули, на которые потенциально влияет данный, считаются устаревшими и должны перекомпилироваться, кроме тех, которые больше не нужны. Реализация может уменьшить стоимость перекомпиляции, если установит, что данные изменения не повлияли на модули, которые находились под потенциальным влиянием данного.
Перекомпилирование субмодупей некоторого модуля на сам этот модуль никакого ваня. ния не оказывает. Изменения в тела подпрограммы или пакета не влияют на другие компилируемые модули (кроме субмодулей этого тела), так как эти компилируемые модули имеют доступ только к спецификации подпрограммы или пакета. В реализации допустимы описанные ниже отступления от этого правила, связанные с открытыми подстановками, некоторыми оптимизациями, осуществляемыми компилятором, и некоторымн аспектами реализации настраиваемых программных модулей. ° Если прагма !М(.(МЕ применяется к описанию подпрограммы в спецификации пакета, то открытая подстановка возможна, только если тело пакета откомпилировано раньше модулей, вызывающих эту подпрограмму.
В таком случае открытая подстановка создает зависимость вызывающего модуля от тела пакета; компилятор должен распознавать такую зависимость при определении необходимости перекомпиляции. Если вызывающий модуль компилируется раньше, чем тело пакета, то для таких вызовов прагма (М()МЕ может игнорироваться компилятором (при этом может быть выдано предупремгдение о невозможности открытой подстановки). То же относится и к раздельно компилируемой подпрограмме, к которой применя. ется прагма !М(.(МЕ. . С цепью оптимизации реализация может компилировать несколько модулей данной компиляции, создавая при этом дальнейшие зависимости между этими компилируемыми моду.
лями. Эти зависимости должны учитываться компилятором для определения необходимых перекомпиляций. ° Реализация может требовать, чтобы описание настройки и соответствующее тело были частями одной и той же компиляции независимо от того, раздельно ли компилируется настраиваемый модуль или он локален в другом компилируемом модуле. Реализация может также требовать, чтобы субмодули настраиваемого модуля были частью одной и той же компиляции. Примеры порядка компиляции: а.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
