Текущая версия |
Ваш текст |
Строка 1: |
Строка 1: |
- | <P STYLE="margin-bottom: 0cm">Языки программирования 24.10.06</P>
| + | == From Ebaums Inc to MurkLoar. == |
- | <P STYLE="margin-bottom: 0cm"><BR>
| + | We at EbaumsWorld consider you as disgrace of human race. |
- | </P>
| + | Your faggotry level exceeded any imaginable levels, and therefore we have to inform you that your pitiful resourse should be annihilated. |
- | <P STYLE="margin-bottom: 0cm">Вставочка в конец 4 главы:</P>
| + | Dig yourself a grave - you will need it. |
- | <P STYLE="margin-bottom: 0cm">Та форма, которая принята в совр ЯП, не
| + | |
- | единственна. Форма, принятая в Си шарп, основана на динамическом
| + | |
- | контроле типов.</P>
| + | |
- | <P STYLE="margin-bottom: 0cm"><BR>
| + | |
- | </P>
| + | |
- | <P STYLE="margin-bottom: 0cm">До этого рассм позиционное соответствие
| + | |
- | параметров. То есть у каждого параметра есть свой номер, и досутп
| + | |
- | осущ по нему.</P>
| + | |
- | <P STYLE="margin-bottom: 0cm">Есть ещё ключевое соответствие, где
| + | |
- | доступ осуществляется по имени.</P>
| + | |
- | <P STYLE="margin-bottom: 0cm">Пример Ада:</P>
| + | |
- | <P STYLE="margin-bottom: 0cm">procedure P(A, B, C:T);</P>
| + | |
- | <P STYLE="margin-bottom: 0cm">можно ввести X, Y, Z:T</P>
| + | |
- | <P STYLE="margin-bottom: 0cm">и при позиционном обращении</P>
| + | |
- | <P STYLE="margin-bottom: 0cm">P(X, Y, Z) и A соотв X, и т. д.</P>
| + | |
- | <P STYLE="margin-bottom: 0cm"><BR>
| + | |
- | </P>
| + | |
- | <P STYLE="margin-bottom: 0cm">Но в Аде есть ещё ключевое
| + | |
- | соответствие. Можно указать:</P>
| + | |
- | <P STYLE="margin-bottom: 0cm">P(A=>X, B=>Y, C=>Z);</P>
| + | |
- | <P STYLE="margin-bottom: 0cm">порядок в этом случае совершенно не
| + | |
- | важен</P>
| + | |
- | <P STYLE="margin-bottom: 0cm">P*(B=>Y, C=>Z, A=>X)</P>
| + | |
- | <P STYLE="margin-bottom: 0cm"><BR>
| + | |
- | </P>
| + | |
- | <P STYLE="margin-bottom: 0cm">Клбючевое соотв есть ещё в VB.</P>
| + | |
- | <P STYLE="margin-bottom: 0cm"><BR>
| + | |
- | </P>
| + | |
- | <P STYLE="margin-bottom: 0cm">Можно пойти дальше и ещё задать
| + | |
- | умолчания. Например, это есть в C++. В случае, если параметр
| + | |
- | отсутствует, подставляется значение по умолчанию.</P>
| + | |
- | <P STYLE="margin-bottom: 0cm">Void f(int x, int y=1);</P>
| + | |
- | <P STYLE="margin-bottom: 0cm">параметры по умолч должны быть
| + | |
- | последними. Тогда можно вызывать</P>
| + | |
- | <P STYLE="margin-bottom: 0cm">F(0), который соотв F(0,1)</P>
| + | |
- | <P STYLE="margin-bottom: 0cm">это приводит к переменному списку
| + | |
- | параметров.</P>
| + | |
- | <P STYLE="margin-bottom: 0cm"><BR>
| + | |
- | </P>
| + | |
- | <P STYLE="margin-bottom: 0cm">Это спорная практика.</P>
| + | |
- | <P STYLE="margin-bottom: 0cm">Фактически, получается две функции:</P>
| + | |
- | <P STYLE="margin-bottom: 0cm">f(int);</P>
| + | |
- | <P STYLE="margin-bottom: 0cm">f(int, int);</P>
| + | |
- | <P STYLE="margin-bottom: 0cm">и используется механизм перекрытия
| + | |
- | имён.
| + | |
- | </P>
| + | |
- | <P STYLE="margin-bottom: 0cm">Понятно, что параметры по умолчанию
| + | |
- | можно проэмулировать путём задания нескольких функций: f(int x) {f(x,
| + | |
- | 1);}</P>
| + | |
- | <P STYLE="margin-bottom: 0cm"><BR>
| + | |
- | </P>
| + | |
- | <P STYLE="margin-bottom: 0cm">Задание всякого рода умолчаний
| + | |
- | считается дурным тоном. Например, умолчания активно использовались в
| + | |
- | PL/1, и это один из его недостатков, так как эти умолчания зависили
| + | |
- | от окружения. Поэтому при проектировании ЯП старались избавляться от
| + | |
- | разного рода умолчаний.</P>
| + | |
- | <P STYLE="margin-bottom: 0cm"><BR>
| + | |
- | </P>
| + | |
- | <P STYLE="margin-bottom: 0cm">В С++ Страуструп описывает ситуацию о
| + | |
- | стандартизации С++. Хорошо выверенное, локальное, удобное предложение
| + | |
- | не прошло. Примером такого предложения является предложение MS о
| + | |
- | ключевых параметрах, в дополнение к ключевым парампетрам.
| + | |
- | </P>
| + | |
- | <P STYLE="margin-bottom: 0cm">Основная позиция комитета по
| + | |
- | стандартизации – необязательность этого. Это удобно, но
| + | |
- | технологическая потребность некритична.</P>
| + | |
- | <P STYLE="margin-bottom: 0cm"><BR>
| + | |
- | </P>
| + | |
- | <P STYLE="margin-bottom: 0cm">Совр ЯП не поддерживают ни ключевые
| + | |
- | параметры, ни параметры по умолчанию.</P>
| + | |
- | <P STYLE="margin-bottom: 0cm"><BR>
| + | |
- | </P>
| + | |
- | <P STYLE="margin-bottom: 0cm">Почему в VB это есть:</P>
| + | |
- | <P STYLE="margin-bottom: 0cm">Если пытьаться использовать
| + | |
- | OLE-автоматизацию, суть в том, что специальные программы могут
| + | |
- | выступать как серверы OLE-автоматизации. Компоненты в Windows предст
| + | |
- | собой OLE-серверы, и они предлагают набор функций. Популярные
| + | |
- | программы: Word. Лектор, когда писал свою программу, использовал Word
| + | |
- | для проверки правописания. Можно вызвать метод checkspelling, в общем
| + | |
- | случае у него порядка 10 параметров. Естественно, что в большинстве
| + | |
- | случаев программист задаёт два-три параметра, осталные по умолчанию.</P>
| + | |
- | <P STYLE="margin-bottom: 0cm">Лектору это напомнило опыт
| + | |
- | программирования на Фортране, исп стандартной библиотеки. Там
| + | |
- | основным способом передачи данных между модулями – через
| + | |
- | параметры. И там у функции бывало по 10-15 параметров. Наличие
| + | |
- | подобных интерфейсов свидетельствует о плохом проектировании.</P>
| + | |
- | <P STYLE="margin-bottom: 0cm"><BR>
| + | |
- | </P>
| + | |
- | <P STYLE="margin-bottom: 0cm">Прав Вирт, Когда утверждает, что
| + | |
- | сложность языка переходит на сложность создаваемых проектов.
| + | |
- | Недостатки дизайна нивелируются дополнительными языковыми
| + | |
- | конструкциями.</P>
| + | |
- | <P STYLE="margin-bottom: 0cm"><BR>
| + | |
- | </P>
| + | |
- | <P STYLE="margin-bottom: 0cm">Простые языки – Оберон, Модула-2
| + | |
- | – на них нет сложных систем. Сложные системы строятся на
| + | |
- | сложных языках.</P>
| + | |
- | <P STYLE="margin-bottom: 0cm"><BR>
| + | |
- | </P>
| + | |
- | <P STYLE="margin-bottom: 0cm">Глава 5.
| + | |
- | </P>
| + | |
- | <P STYLE="margin-bottom: 0cm">п.1. Понятие типов в традиционных ЯП.
| + | |
- | Уникальность типа.</P>
| + | |
- | <P STYLE="margin-bottom: 0cm"><BR>
| + | |
- | </P>
| + | |
- | <P STYLE="margin-bottom: 0cm">Чем по большому счёту отличаются
| + | |
- | традиционные ЯП от ОО. ОО опираются на традиционную, но немного
| + | |
- | отличаются. ОО отличаются понятием типа.</P>
| + | |
- | <P STYLE="margin-bottom: 0cm"><BR>
| + | |
- | </P>
| + | |
- | <P STYLE="margin-bottom: 0cm">Понятие типа опирается на 4 аксиомы
| + | |
- | уникальности типа:</P>
| + | |
- | <OL>
| + | |
- | <LI><P STYLE="margin-bottom: 0cm">Каждый объект данных принадлежит
| + | |
- | единственному типу данных. - самое сильное ограничеиние традиц ЯП</P>
| + | |
- | <LI><P STYLE="margin-bottom: 0cm">У каждого типа есть имя, для
| + | |
- | анаонимных – неявное. Например, когда в Паскале описываем var
| + | |
- | A : array [1..N] of integer; 1..N – анаонимный тип. В Аде это
| + | |
- | два типа. Типы считаются различными, если их имена различны. Эта
| + | |
- | аксиома носит назван ие именная эквив типов</P>
| + | |
- | <LI><P STYLE="margin-bottom: 0cm">Каждая операция над типом данных
| + | |
- | имеет фиксированный тип и порядок операндов. Понятие типа
| + | |
- | характеризуется набором операций.</P>
| + | |
- | <LI><P STYLE="margin-bottom: 0cm">Разные типы данных несовместимы по
| + | |
- | операциям.</P>
| + | |
- | </OL>
| + | |
- | <P STYLE="margin-bottom: 0cm">Вспе 4 аксиомы уточняют понятие строгой
| + | |
- | типизации. Чем строгая отличается от сильной, нигде не сказано.
| + | |
- | Аналогично со слабой типизацией. В любых языках со строгой или
| + | |
- | сильной типизацией выполняется 1 аксиома. Например, скриптовые языки
| + | |
- | не удовл это аксиоме – там есть понятие variant – некий
| + | |
- | тип, который является объединением типов.
| + | |
- | </P>
| + | |
- | <P STYLE="margin-bottom: 0cm">2 аксиома – аксиома именной эквив
| + | |
- | типов. Рад языков от неё отходит. Например: Type T = T1. То есть,
| + | |
- | часто в ЯП вводится синонимия типов. В Си фактически typedef и есть
| + | |
- | определение синонима. Но если про неё забыть, то если типы не имеют
| + | |
- | синонимов, то они различны. В Аде пошли дальше: type T1 is new T . В
| + | |
- | некоторых ЯП существует структурная эквивалентность типов –
| + | |
- | типы эквивалентны, если их структура совпадает. Как только возникают
| + | |
- | ссылочные типы, то завдача может стать алгоритмически неразрешимой.
| + | |
- | Кроме того, имя важно само по себе, ибо тип хар-зуется набром
| + | |
- | операций и именем. Тем не менее недостатки языкового дизаяна
| + | |
- | разрушают концептуальную целостность. Во в Си структурная или именная
| + | |
- | целостность:</P>
| + | |
- | <P STYLE="margin-bottom: 0cm">Struct A {int a, b; }</P>
| + | |
- | <P STYLE="margin-bottom: 0cm">Struct B {int a, b; }</P>
| + | |
- | <P STYLE="margin-bottom: 0cm">Это разные типы, и на первый взгляд
| + | |
- | именная эквивалентность типов. Но в Си раздельная независимая
| + | |
- | трансляция. И в этом случая стандарту удовлетв следующая ситуация:</P>
| + | |
- | <P STYLE="margin-bottom: 0cm">В модуле 1 описана Struct A {int a, b;
| + | |
- | } void F(struct A a);</P>
| + | |
- | <P STYLE="margin-bottom: 0cm">В модуле 2 описана Struct B {int a, b;
| + | |
- | } extern f(struct B b);</P>
| + | |
- | <P STYLE="margin-bottom: 0cm">struct B b;</P>
| + | |
- | <P STYLE="margin-bottom: 0cm">F(b);</P>
| + | |
- | <P STYLE="margin-bottom: 0cm">Это полностью удовлетворяет стандарту,
| + | |
- | и компиляторы должны обрабатывать это правильно. И вылезает
| + | |
- | структурная эквивалентность типов. Дырка в том, что у нас раздельная
| + | |
- | независимая трансляция. Когда мы описываем атрибуты, мы можем их
| + | |
- | немного не так задать, но структурно так же. Но на уровне одного
| + | |
- | модуля структурная эквивалентность не проходит. Концептуальной
| + | |
- | целостности нет. Но в Си++ тот же самый механизм раздельной
| + | |
- | трансляции, но структ эквивалентности нет. Ошибка будет выдана, что
| + | |
- | не найдена функция с необходимым параметрами, на этапе линковки.
| + | |
- | Причём имя функция будет иметь невразумительное имя. Например, у
| + | |
- | Паскаля и Дельфи свой формат объектного файла, свой загрузчик и т.
| + | |
- | д., которые намного богаче, чем стандартные, которые писались для
| + | |
- | ассемблера, где просто указывается, есть имя или нет. Си++ использует
| + | |
- | ту же самую структуру объектного модуля. В первом варианте
| + | |
- | компилятора делалось С++ => C, и когда возникает ситуация
| + | |
- | перекрытия имён, возникает вопрос, как их транслировать в Си, где его
| + | |
- | нет. Был придуман способ name mangling (кодирование имён), который
| + | |
- | позволил контролировать типы данных при сборке. Была принята
| + | |
- | единообразная схема кодирования имён, где содержится информация об
| + | |
- | имени функции и её параметрах, и эти имена будут различны для разных
| + | |
- | struct A и struc B. Но это не будет работать на старых редакторов
| + | |
- | связей, которые обрезали идентификаторы до 6 символов, так как первый
| + | |
- | компилятор на фортране был для IBM 709, где машинное слово было 6
| + | |
- | байт. В современных ОС есть свои форматы исолняемых файлов, и это
| + | |
- | позволяет использовать такие имена.</P>
| + | |
- | <P STYLE="margin-bottom: 0cm"><BR>
| + | |
- | </P>
| + | |
- | <P STYLE="margin-bottom: 0cm">Любой современный ЯП удовл двум
| + | |
- | аксиомам.</P>
| + | |
- | <P STYLE="margin-bottom: 0cm">А вот от четвёртой аксиомы многие
| + | |
- | отступают. Нпример, операция присваивания. Слева и вправа могут
| + | |
- | стоять разные типы. В Си правила преобр сложны, в Си++ ещё сложнее.</P>
| + | |
- | <P STYLE="margin-bottom: 0cm">4 аксиома ослабляется тем, что в ЯП
| + | |
- | есть неявные преобразования. 4 аксиома нарушается часте всего засчёт
| + | |
- | неявных преобразований.</P>
| + | |
- | <P STYLE="margin-bottom: 0cm"><BR>
| + | |
- | </P>
| + | |
- | <P STYLE="margin-bottom: 0cm">Язык Ада обладает наиболее строгой
| + | |
- | типизацией, так как удовлетворяет всем 4 аксиомам.</P>
| + | |
- | <P STYLE="margin-bottom: 0cm"><BR>
| + | |
- | </P>
| + | |
- | <P STYLE="margin-bottom: 0cm">Чем больше онмер аксиомы, тем больше
| + | |
- | отступают.</P>
| + | |
- | <P STYLE="margin-bottom: 0cm"><BR>
| + | |
- | </P>
| + | |
- | <P STYLE="margin-bottom: 0cm">Какие преимущества несё концепция
| + | |
- | уникальности ТД:</P>
| + | |
- | <P STYLE="margin-bottom: 0cm">Каждая операция зафикс, смысл их
| + | |
- | извествен, операции несовместимы, поэтому поведение любого объекта
| + | |
- | данных легко прогнозируемы. Программы получаются как надёжные, так и
| + | |
- | эффективные. То же относительно контроля.
| + | |
- | </P>
| + | |
- | <P STYLE="margin-bottom: 0cm"><BR>
| + | |
- | </P>
| + | |
- | <P STYLE="margin-bottom: 0cm">Проблемы:</P>
| + | |
- | <P STYLE="margin-bottom: 0cm">Полиморфизм операции. 3 аксиома
| + | |
- | говорит, что каждый ТД харак своим набором операций. Даже самый
| + | |
- | первый ЯП, Фортран, был полиморфным. Более того, любой ЯП является
| + | |
- | полиморфным. Это справедливо в первую очередь для встроенных
| + | |
- | операций. Например, даже в асме ADD отвечает разным машинным кодам.
| + | |
- | Тип операции выводится из типов операндов. То есть все стандартные
| + | |
- | операции полиморфны. Совр ЯП как решают проблемф полиморфизма: с
| + | |
- | помощью перекрытия операций. Та мдопускается делать пользовательские
| + | |
- | полиморфные операции (в J и D – нельзя перекрывать стандартные
| + | |
- | операции, в C# и C++ - можно).</P>
| + | |
- | <P STYLE="margin-bottom: 0cm"><BR>
| + | |
- | </P>
| + | |
- | <P STYLE="margin-bottom: 0cm">Ада: есть overloading –
| + | |
- | перекрытие операции – статический полиморфизм, то есть выбор
| + | |
- | производится статически, во время компиляции. Это недостаток. Совр ЯП
| + | |
- | допускают динамический полиморфизм. Интересно, что в О-2 отсутствует
| + | |
- | статич, и присутствует динамический полиморфизм.</P>
| + | |
- | <P STYLE="margin-bottom: 0cm"><BR>
| + | |
- | </P>
| + | |
- | <OL START=2>
| + | |
- | <LI><P STYLE="margin-bottom: 0cm">Янус проблема – объекты
| + | |
- | реального мира играют разныке роли. Как решается проблема в
| + | |
- | традиционных ЯП – объединение типов.</P>
| + | |
- | </OL>
| + | |
- | <P STYLE="margin-bottom: 0cm">И решение 1 проблемы перекрытием, и
| + | |
- | янус проблемы объединением, их проблема в том, что они статические.
| + | |
- | При этом отстутствует какой-либо динамический контроль.
| + | |
- | </P>
| + | |
- | <P STYLE="margin-bottom: 0cm"><BR>
| + | |
- | </P>
| + | |
- | <P STYLE="margin-bottom: 0cm">Во придумал Вирт замечательнй язык
| + | |
- | М-2,, и он вынужден был ввести тип ADDRESS. Напримр, нужно написать
| + | |
- | механизм распределения динамической памяти. И лонично его писать на
| + | |
- | М-2. Там нет шаблонов, ... . И единственный способ сделать это –
| + | |
- | добавить тип ADDRESS. Про тип ADDRESS известно, что к нему приводим
| + | |
- | любой тип-указатель.</P>
| + | |
- | <P STYLE="margin-bottom: 0cm"><BR>
| + | |
- | </P>
| + | |
- | <P STYLE="margin-bottom: 0cm">Что являлось разочарованием для Вирта:
| + | |
- | программисты используют ADDRESS чаще, чем надо. При этом сразу же
| + | |
- | ломается контроль типов. Что автоматически делает язык ненадёжным.</P>
| + | |
- | <P STYLE="margin-bottom: 0cm"><BR>
| + | |
- | </P>
| + | |
- | <P STYLE="margin-bottom: 0cm">Именно поэтому пришла другая парадигма
| + | |
- | – процедурно-объектная.</P>
| + | |
- | <P STYLE="margin-bottom: 0cm"><BR>
| + | |
- | </P>
| + | |
- | <P STYLE="margin-bottom: 0cm"><BR>
| + | |
- | </P>
| + | |
- | <P STYLE="margin-bottom: 0cm">П2. Логические модули и определение
| + | |
- | типов.</P>
| + | |
- | <P STYLE="margin-bottom: 0cm">Ада, М-2, О-2, Дельфи.</P>
| + | |
- | <P STYLE="margin-bottom: 0cm">Самые простые модели – М2, о2</P>
| + | |
- | <P STYLE="margin-bottom: 0cm">Самая сложная – Ада.</P>
| + | |
- | <P STYLE="margin-bottom: 0cm">Осн на понятиях:</P>
| + | |
- | <OL>
| + | |
- | <LI><P STYLE="margin-bottom: 0cm">Объявление типа</P>
| + | |
- | <LI><P STYLE="margin-bottom: 0cm">Понятие модуля</P>
| + | |
- | <LI><P STYLE="margin-bottom: 0cm">Объявление объекта данных</P>
| + | |
- | </OL>
| + | |
- | <P STYLE="margin-bottom: 0cm"><BR>
| + | |
- | </P>
| + | |
- | <P STYLE="margin-bottom: 0cm">Объявление задаёт имя и структуру.</P>
| + | |
- | <P STYLE="margin-bottom: 0cm">Во всех этих языках объявление
| + | |
- | начинается с type</P>
| + | |
- | <P STYLE="margin-bottom: 0cm">type имя is/= record, array, new</P>
| + | |
- | <P STYLE="margin-bottom: 0cm"><BR>
| + | |
- | </P>
| + | |
- | <P STYLE="margin-bottom: 0cm">А что, если не определить тип –
| + | |
- | получится АТД, то есть тип, у которого отсутствует структура.</P>
| + | |
- | <P STYLE="margin-bottom: 0cm"><BR>
| + | |
- | </P>
| + | |
- | <P STYLE="margin-bottom: 0cm">Если структуру типов опуститть можно,
| + | |
- | то набор операций опустить нельзя.</P>
| + | |
- | <P STYLE="margin-bottom: 0cm"><BR>
| + | |
- | </P>
| + | |
- | <P STYLE="margin-bottom: 0cm">Во многих языках понятие модуля очень
| + | |
- | широко, и может служить не только для определения данных, но и для
| + | |
- | констант и операций.</P>
| + | |
- | <P STYLE="margin-bottom: 0cm"><BR>
| + | |
- | </P>
| + | |
- | <P STYLE="margin-bottom: 0cm">Кроме понятия логического модуля есть
| + | |
- | понятие физического модуля. В рпостых ЯП понятие физмодуля слит с
| + | |
- | логическим модулем, то же в Дельфи, а в Аде не так.</P>
| + | |
- | <P STYLE="margin-bottom: 0cm"><BR>
| + | |
- | </P>
| + | |
- | <P STYLE="margin-bottom: 0cm">Пока будем считать, что физмодуль один,
| + | |
- | но он разбит на кусочки.</P>
| + | |
- | <P STYLE="margin-bottom: 0cm"><BR>
| + | |
- | </P>
| + | |
- | <P STYLE="margin-bottom: 0cm">При определении модуля главное –
| + | |
- | определить взаимодействие с другими модулями.</P>
| + | |
- | <P STYLE="margin-bottom: 0cm"><BR>
| + | |
- | </P>
| + | |
- | <P STYLE="margin-bottom: 0cm">Рассмотрим Си. Всё, что сказал лектор,
| + | |
- | можно реализовать на Си, с помощью соотв технологии. Например, что
| + | |
- | является модулем на языке Си – файл. Причём, у каждого модуля
| + | |
- | есть интерфейс, есть реализация. На Си интерфейс в хедере.</P>
| + | |
- | <P STYLE="margin-bottom: 0cm"><BR>
| + | |
- | </P>
| + | |
- | <P STYLE="margin-bottom: 0cm">Типичный пример – stdio.h</P>
| + | |
- | <P STYLE="margin-bottom: 0cm">Тип FILE – пример АТД.
| + | |
- | </P>
| + | |
- | <P STYLE="margin-bottom: 0cm">Чем плох язык Си – соотв
| + | |
- | технология должна реализовываться ручками, и никакого контроля нет.
| + | |
- | Но иногда так и приходится делать. Все системы защиты в Си – не
| + | |
- | от взломщика, а от дурака.</P>
| + | |
- | <P STYLE="margin-bottom: 0cm"><BR>
| + | |
- | </P>
| + | |
- | <P STYLE="margin-bottom: 0cm">Поэтому особое внимание уделяется
| + | |
- | межмодульным связям.</P>
| + | |
- | <P STYLE="margin-bottom: 0cm"><BR>
| + | |
- | </P>
| + | |
- | <P STYLE="margin-bottom: 0cm">Сама логичная концепция – в М2 и
| + | |
- | Дельфи</P>
| + | |
- | <P STYLE="margin-bottom: 0cm">Есть понятие библиотечного модуля.</P>
| + | |
- | <P STYLE="margin-bottom: 0cm">Вообще, модули деятся на следующие
| + | |
- | виды:</P>
| + | |
- | <OL>
| + | |
- | <LI><P STYLE="margin-bottom: 0cm">Главный</P>
| + | |
- | <LI><P STYLE="margin-bottom: 0cm">Библиотечный</P>
| + | |
- | <LI><P STYLE="margin-bottom: 0cm">Локальный</P>
| + | |
- | </OL>
| + | |
- | <P STYLE="margin-bottom: 0cm">Главный модуль:</P>
| + | |
- | <P STYLE="margin-bottom: 0cm">MODELU name;</P>
| + | |
- | <P STYLE="margin-bottom: 0cm">объявления;</P>
| + | |
- | <P STYLE="margin-bottom: 0cm">begin</P>
| + | |
- | <P STYLE="margin-bottom: 0cm">выполнение;</P>
| + | |
- | <P STYLE="margin-bottom: 0cm">end.</P>
| + | |
- | <P STYLE="margin-bottom: 0cm"><BR>
| + | |
- | </P>
| + | |
- | <P STYLE="margin-bottom: 0cm">В аде два типа библиотечных модулей:</P>
| + | |
- | <OL>
| + | |
- | <LI><P STYLE="margin-bottom: 0cm">DEFINITION MODULE name begin end
| + | |
- | name. - только объявления</P>
| + | |
- | <LI><P STYLE="margin-bottom: 0cm">IMPLEMENTATION MODULE name
| + | |
- | объявления и определения подпрограмм и ... begin реализация end
| + | |
- | name. - объявоеия и реализация</P>
| + | |
- | </OL>
| + | |
- | <P STYLE="margin-bottom: 0cm">Пример:</P>
| + | |
- | <P STYLE="margin-bottom: 0cm">DEFINITION MODULE stacks</P>
| + | |
- | <P STYLE="margin-bottom: 0cm">TYPE Stack = ...;</P>
| + | |
- | <P STYLE="margin-bottom: 0cm">PROCEDURE Push(var S:Stack; X:Integer);</P>
| + | |
- | <P STYLE="margin-bottom: 0cm">PROCEDURE Pop(var S:Stack):INTEGER;</P>
| + | |
- | <P STYLE="margin-bottom: 0cm">PROCEDURE Peek(var S:Stack):INTEGER;</P>
| + | |
- | <P STYLE="margin-bottom: 0cm">PROCEDURE IsEmpty(var S:Stack):BOOLEAN;</P>
| + | |
- | <P STYLE="margin-bottom: 0cm">END stacks;</P>
| + | |
- | <P STYLE="margin-bottom: 0cm"><BR>
| + | |
- | </P>
| + | |
- | <P STYLE="margin-bottom: 0cm">А в IMPLEMENTATION MODULE описываем
| + | |
- | полностью прототипы и их тела.</P>
| + | |
- | <P STYLE="margin-bottom: 0cm"><BR>
| + | |
- | </P>
| + | |
- | <P STYLE="margin-bottom: 0cm">DEFINITION MODULE – список
| + | |
- | экспорта.</P>
| + | |
- | <P STYLE="margin-bottom: 0cm"><BR>
| + | |
- | </P>
| + | |
- | <P STYLE="margin-bottom: 0cm">Если что-то оформлено в виде
| + | |
- | библиотечного модуля, ещё кому-то надо.</P>
| + | |
- | <P STYLE="margin-bottom: 0cm"><BR>
| + | |
- | </P>
| + | |
- | <P STYLE="margin-bottom: 0cm">В Модуле 2 интерфейс и реализация
| + | |
- | находятся в разных физ модулях</P>
| + | |
- | <P STYLE="margin-bottom: 0cm"><BR>
| + | |
- | </P>
| + | |
- | <P STYLE="margin-bottom: 0cm">В Паскале-Дельфи</P>
| + | |
- | <P STYLE="margin-bottom: 0cm">Две части слиты в один физмодуль, но он
| + | |
- | разбит на две логические части, которые нельзя игнорировать вообще:</P>
| + | |
- | <P STYLE="margin-bottom: 0cm">unit name;</P>
| + | |
- | <P STYLE="margin-bottom: 0cm">interface</P>
| + | |
- | <P STYLE="margin-bottom: 0cm">объявления</P>
| + | |
- | <P STYLE="margin-bottom: 0cm">implementation</P>
| + | |
- | <P STYLE="margin-bottom: 0cm">дополнительные объявления, реализация</P>
| + | |
- | <P STYLE="margin-bottom: 0cm">begin</P>
| + | |
- | <P STYLE="margin-bottom: 0cm">операторы</P>
| + | |
- | <P STYLE="margin-bottom: 0cm">end.</P>
| + | |
- | <P STYLE="margin-bottom: 0cm">В дельфи более кудрявая форма begin
| + | |
- | операторы</P>
| + | |
- | <P STYLE="margin-bottom: 0cm"><BR>
| + | |
- | </P>
| + | |
- | <P STYLE="margin-bottom: 0cm">С точки зрения кода, где объектный код
| + | |
- | генерируется – он состоит из таблицу имён, объектный код
| + | |
- | реализации. И таблицы имён в implementation нет, так как они никому
| + | |
- | не нужны. А имена нужны только для того, чтобы ссылаться на них
| + | |
- | извне.</P>
| + | |
- | <P STYLE="margin-bottom: 0cm"><BR>
| + | |
- | </P>
| + | |
- | <P STYLE="margin-bottom: 0cm">Top Speed Modula-2 – очень быстро
| + | |
- | транслировалась, и там def-файлы вообще не транслировалось, всё
| + | |
- | делалось на лету.</P>
| + | |
- | <P STYLE="margin-bottom: 0cm"><BR>
| + | |
- | </P>
| + | |
- | <P STYLE="margin-bottom: 0cm">Как происходит взаимодействие (на
| + | |
- | примере Модулы-2):</P>
| + | |
- | <P STYLE="margin-bottom: 0cm">Какова структура проекта</P>
| + | |
- | <P STYLE="margin-bottom: 0cm"><BR>
| + | |
- | </P>
| + | |
- | <P STYLE="margin-bottom: 0cm">В первой реализации Модулы-2 даже был
| + | |
- | раздел EXPORT, где указывались экспортируемые имена.</P>
| + | |
- | <P STYLE="margin-bottom: 0cm"><BR>
| + | |
- | </P>
| + | |
- | <P STYLE="margin-bottom: 0cm">Два вида видимости:</P>
| + | |
- | <OL>
| + | |
- | <LI><P STYLE="margin-bottom: 0cm">Потенциальная – видно при
| + | |
- | наличии уточнений. Например, именем модуля: M.name</P>
| + | |
- | <LI><P STYLE="margin-bottom: 0cm">Непосредственная</P>
| + | |
- | </OL>
| + | |
- | | + | |
- | {{Языки Программирования}}
| + | |