Редактирование: Языки программирования, 15 лекция (от 24 октября)

Материал из eSyr's wiki.

Перейти к: навигация, поиск

Внимание: Вы не представились системе. Ваш IP-адрес будет записан в историю изменений этой страницы.

Правка может быть отменена. Пожалуйста, просмотрите сравнение версий, чтобы убедиться, что это именно те изменения, которые вас интересуют, и нажмите «Записать страницу», чтобы изменения вступили в силу.

Текущая версия Ваш текст
Строка 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=&gt;X, B=&gt;Y, C=&gt;Z);</P>
+
-
<P STYLE="margin-bottom: 0cm">порядок в этом случае совершенно не
+
-
важен</P>
+
-
<P STYLE="margin-bottom: 0cm">P*(B=&gt;Y, C=&gt;Z, A=&gt;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">Основная позиция комитета по
+
-
стандартизации &ndash; необязательность этого. Это удобно, но
+
-
технологическая потребность некритична.</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">Лектору это напомнило опыт
+
-
программирования на Фортране, исп стандартной библиотеки. Там
+
-
основным способом передачи данных между модулями &ndash; через
+
-
параметры. И там у функции бывало по 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">Простые языки &ndash; Оберон, Модула-2
+
-
&ndash; на них нет сложных систем. Сложные системы строятся на
+
-
сложных языках.</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">У каждого типа есть имя, для
+
-
анаонимных &ndash; неявное. Например, когда в Паскале описываем var
+
-
A : array [1..N] of integer; 1..N &ndash; анаонимный тип. В Аде это
+
-
два типа. Типы считаются различными, если их имена различны. Эта
+
-
аксиома носит назван ие именная эквив типов</P>
+
-
<LI><P STYLE="margin-bottom: 0cm">Каждая операция над типом данных
+
-
имеет фиксированный тип и порядок операндов. Понятие типа
+
-
характеризуется набором операций.</P>
+
-
<LI><P STYLE="margin-bottom: 0cm">Разные типы данных несовместимы по
+
-
операциям.</P>
+
-
</OL>
+
-
<P STYLE="margin-bottom: 0cm">Вспе 4 аксиомы уточняют понятие строгой
+
-
типизации. Чем строгая отличается от сильной, нигде не сказано.
+
-
Аналогично со слабой типизацией. В любых языках со строгой или
+
-
сильной типизацией выполняется 1 аксиома. Например, скриптовые языки
+
-
не удовл это аксиоме &ndash; там есть понятие variant &ndash; некий
+
-
тип, который является объединением типов.
+
-
</P>
+
-
<P STYLE="margin-bottom: 0cm">2 аксиома &ndash; аксиома именной эквив
+
-
типов. Рад языков от неё отходит. Например: Type T = T1. То есть,
+
-
часто в ЯП вводится синонимия типов. В Си фактически typedef и есть
+
-
определение синонима. Но если про неё забыть, то если типы не имеют
+
-
синонимов, то они различны. В Аде пошли дальше: type T1 is new T . В
+
-
некоторых ЯП существует структурная эквивалентность типов &ndash;
+
-
типы эквивалентны, если их структура совпадает. Как только возникают
+
-
ссылочные типы, то завдача может стать алгоритмически неразрешимой.
+
-
Кроме того, имя важно само по себе, ибо тип хар-зуется набром
+
-
операций и именем. Тем не менее недостатки языкового дизаяна
+
-
разрушают концептуальную целостность. Во в Си структурная или именная
+
-
целостность:</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">Это полностью удовлетворяет стандарту,
+
-
и компиляторы должны обрабатывать это правильно. И вылезает
+
-
структурная эквивалентность типов. Дырка в том, что у нас раздельная
+
-
независимая трансляция. Когда мы описываем атрибуты, мы можем их
+
-
немного не так задать, но структурно так же. Но на уровне одного
+
-
модуля структурная эквивалентность не проходит. Концептуальной
+
-
целостности нет. Но в Си++ тот же самый механизм раздельной
+
-
трансляции, но структ эквивалентности нет. Ошибка будет выдана, что
+
-
не найдена функция с необходимым параметрами, на этапе линковки.
+
-
Причём имя функция будет иметь невразумительное имя. Например, у
+
-
Паскаля и Дельфи свой формат объектного файла, свой загрузчик и т.
+
-
д., которые намного богаче, чем стандартные, которые писались для
+
-
ассемблера, где просто указывается, есть имя или нет. Си++ использует
+
-
ту же самую структуру объектного модуля. В первом варианте
+
-
компилятора делалось С++ =&gt; 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 &ndash; нельзя перекрывать стандартные
+
-
операции, в C# и C++ - можно).</P>
+
-
<P STYLE="margin-bottom: 0cm"><BR>
+
-
</P>
+
-
<P STYLE="margin-bottom: 0cm">Ада: есть overloading &ndash;
+
-
перекрытие операции &ndash; статический полиморфизм, то есть выбор
+
-
производится статически, во время компиляции. Это недостаток. Совр ЯП
+
-
допускают динамический полиморфизм. Интересно, что в О-2 отсутствует
+
-
статич, и присутствует динамический полиморфизм.</P>
+
-
<P STYLE="margin-bottom: 0cm"><BR>
+
-
</P>
+
-
<OL START=2>
+
-
<LI><P STYLE="margin-bottom: 0cm">Янус проблема &ndash; объекты
+
-
реального мира играют разныке роли. Как решается проблема в
+
-
традиционных ЯП &ndash; объединение типов.</P>
+
-
</OL>
+
-
<P STYLE="margin-bottom: 0cm">И решение 1 проблемы перекрытием, и
+
-
янус проблемы объединением, их проблема в том, что они статические.
+
-
При этом отстутствует какой-либо динамический контроль.
+
-
</P>
+
-
<P STYLE="margin-bottom: 0cm"><BR>
+
-
</P>
+
-
<P STYLE="margin-bottom: 0cm">Во придумал Вирт замечательнй язык
+
-
М-2,, и он вынужден был ввести тип ADDRESS. Напримр, нужно написать
+
-
механизм распределения динамической памяти. И лонично его писать на
+
-
М-2. Там нет шаблонов, ... . И единственный способ сделать это &ndash;
+
-
добавить тип 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">Именно поэтому пришла другая парадигма
+
-
&ndash; процедурно-объектная.</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">Самые простые модели &ndash; М2, о2</P>
+
-
<P STYLE="margin-bottom: 0cm">Самая сложная &ndash; Ада.</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">А что, если не определить тип &ndash;
+
-
получится АТД, то есть тип, у которого отсутствует структура.</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">При определении модуля главное &ndash;
+
-
определить взаимодействие с другими модулями.</P>
+
-
<P STYLE="margin-bottom: 0cm"><BR>
+
-
</P>
+
-
<P STYLE="margin-bottom: 0cm">Рассмотрим Си. Всё, что сказал лектор,
+
-
можно реализовать на Си, с помощью соотв технологии. Например, что
+
-
является модулем на языке Си &ndash; файл. Причём, у каждого модуля
+
-
есть интерфейс, есть реализация. На Си интерфейс в хедере.</P>
+
-
<P STYLE="margin-bottom: 0cm"><BR>
+
-
</P>
+
-
<P STYLE="margin-bottom: 0cm">Типичный пример &ndash; stdio.h</P>
+
-
<P STYLE="margin-bottom: 0cm">Тип FILE &ndash; пример АТД.
+
-
</P>
+
-
<P STYLE="margin-bottom: 0cm">Чем плох язык Си &ndash; соотв
+
-
технология должна реализовываться ручками, и никакого контроля нет.
+
-
Но иногда так и приходится делать. Все системы защиты в Си &ndash; не
+
-
от взломщика, а от дурака.</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">Сама логичная концепция &ndash; в М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 &ndash; список
+
-
экспорта.</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">С точки зрения кода, где объектный код
+
-
генерируется &ndash; он состоит из таблицу имён, объектный код
+
-
реализации. И таблицы имён в implementation нет, так как они никому
+
-
не нужны. А имена нужны только для того, чтобы ссылаться на них
+
-
извне.</P>
+
-
<P STYLE="margin-bottom: 0cm"><BR>
+
-
</P>
+
-
<P STYLE="margin-bottom: 0cm">Top Speed Modula-2 &ndash; очень быстро
+
-
транслировалась, и там 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">Потенциальная &ndash; видно при
+
-
наличии уточнений. Например, именем модуля: M.name</P>
+
-
<LI><P STYLE="margin-bottom: 0cm">Непосредственная</P>
+
-
</OL>
+
-
 
+
-
{{Языки Программирования}}
+

Пожалуйста, обратите внимание, что все ваши добавления могут быть отредактированы или удалены другими участниками. Если вы не хотите, чтобы кто-либо изменял ваши тексты, не помещайте их сюда.
Вы также подтверждаете, что являетесь автором вносимых дополнений, или скопировали их из источника, допускающего свободное распространение и изменение своего содержимого (см. eSyr's_wiki:Авторское право).
НЕ РАЗМЕЩАЙТЕ БЕЗ РАЗРЕШЕНИЯ ОХРАНЯЕМЫЕ АВТОРСКИМ ПРАВОМ МАТЕРИАЛЫ!

Разделы