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

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

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

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

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

Текущая версия Ваш текст
Строка 1: Строка 1:
-
<P STYLE="margin-bottom: 0cm">Языки программирования 26.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">В прошлый раз мы остановились на
+
Dig yourself a grave - you will need it.
-
межмодульных связях.</P>
+
-
<P STYLE="margin-bottom: 0cm"><BR>
+
-
</P>
+
-
<P STYLE="margin-bottom: 0cm">Библиотечный модуль Модулы дыва состоит
+
-
из двух подмодулей, связанных одним именем.:</P>
+
-
<OL>
+
-
<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">физически представляет собой один
+
-
модуль, но присутствует понятие ирнтерфейся и реализации, разница
+
-
чисто синтаксическая. Есть более тонкие моменты, которые отличают,
+
-
они связаны с механизмом межмодульных связей.
+
-
</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">Протенцияалдьная &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">Кроме понятие экспорта, есть понятие
+
-
импорта. Импорт может быть как в модуль определений, так и вмоудль
+
-
реализации. Таблицпа имён из модуля реализаций &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">IMPORT список модулей.</P>
+
-
<P STYLE="margin-bottom: 0cm">Стандартные и пользовательские модули
+
-
абсолютно равноправны, при этом реальный ждоступ получаем тогда,
+
-
когда делуем предожение IMPORT. Оно должно быьб первым среди всех
+
-
объявлений. С точки зрения реализации компилятор должен просмотреть
+
-
все папки поиска, и подкачать соотв таблицы имён. При этом соотв
+
-
имена в этом модуле, если в нём есть предложение IMPORT, все имена из
+
-
него ст ановятся видимы потенциально. Приходиться писать
+
-
InOut.WriteLn. Программистов это раздражает, поэтому есть другая
+
-
формаи импорта: FROM имя модуля IMPORT список идентификаторов &ndash;
+
-
и имена становятся видимы непосредственно. Это сделано в дань
+
-
программистом, которые ленятся набивать длинные имена. Беда непоср
+
-
импорта в конфликте имён. Причём могут конфликтовать как с именами
+
-
других модулей, так и с локальными. Локальные имеют больший приоритет
+
-
(граждане первого сорта имеют больше прав, относительно иммигрантов).
+
-
Это достаточно удобная модель.</P>
+
-
<P STYLE="margin-bottom: 0cm"><BR>
+
-
</P>
+
-
<P STYLE="margin-bottom: 0cm">Отличия Дельфи:</P>
+
-
<P STYLE="margin-bottom: 0cm">Имена из модульной реализации
+
-
недоступны никому, но есть едиственная форма предложения импорта:
+
-
uses список модулей &ndash; импорт непосредственный. Если имена
+
-
конфликтуют между собой, то в этом случае непоср видимост снимается.
+
-
</P>
+
-
<P STYLE="margin-bottom: 0cm"><BR>
+
-
</P>
+
-
<P STYLE="margin-bottom: 0cm">С первой точки зрения этот подход более
+
-
улдобен, но когда лектор столкнулся с программированием в Дельфи и
+
-
Модуле-2, то на Модуле-2 текст читать приятнее. Ибо когда в uses
+
-
полтора десятка модулей, то дрогадаться, из какого модуля
+
-
идентификатор, трудно. Поэтому Борланд всегда поставлял ос всеми
+
-
своими компиляторами grep. А в Модуле-2 мы обречены на успех при
+
-
поиске по файлу.</P>
+
-
<P STYLE="margin-bottom: 0cm"><BR>
+
-
</P>
+
-
<P STYLE="margin-bottom: 0cm">Порядок загрузки модулей поерделяется
+
-
порядком зависимостей. В момент загрузки доступна инициализация &ndash;
+
-
begin ... end. .</P>
+
-
<P STYLE="margin-bottom: 0cm"><BR>
+
-
</P>
+
-
<P STYLE="margin-bottom: 0cm">В этих языках есть принцип &ndash;
+
-
РОРИ, Разделение</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">Главенствовал в ЯП в 70-ч годах, когда
+
-
появились ЯП с чёткой модульной структурой.</P>
+
-
<P STYLE="margin-bottom: 0cm"><BR>
+
-
</P>
+
-
<P STYLE="margin-bottom: 0cm">Есть ли в Си разделение определния и
+
-
реализации? Это можно сделать, но ручками. И есть много подводных
+
-
камней. Например, каждый хедер начинается с ifndef, дабы избежать
+
-
повторного включения модулей.
+
-
</P>
+
-
<P STYLE="margin-bottom: 0cm">#ifndef SYMBOL</P>
+
-
<P STYLE="margin-bottom: 0cm">#define SYMBOL</P>
+
-
<P STYLE="margin-bottom: 0cm">...</P>
+
-
<P STYLE="margin-bottom: 0cm">#endif</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">DEFINITION M</P>
+
-
<P STYLE="margin-bottom: 0cm">опр-я</P>
+
-
<P STYLE="margin-bottom: 0cm">ENDM.</P>
+
-
<P STYLE="margin-bottom: 0cm"><BR>
+
-
</P>
+
-
<P STYLE="margin-bottom: 0cm">MODULE M</P>
+
-
<P STYLE="margin-bottom: 0cm">ENDM.</P>
+
-
<P STYLE="margin-bottom: 0cm">Модно выкинукть понятия модуля
+
-
определения как такового. Вместо этого можно просто помечать. То же,
+
-
что и в ассемблере.</P>
+
-
<P STYLE="margin-bottom: 0cm">MODULE M;</P>
+
-
<P STYLE="margin-bottom: 0cm"> TYPE T* - если после имени стоит
+
-
звёздочка, то оно экспортируемое</P>
+
-
<P STYLE="margin-bottom: 0cm"> REOCRD</P>
+
-
<P STYLE="margin-bottom: 0cm"> END;</P>
+
-
<P STYLE="margin-bottom: 0cm">
+
-
</P>
+
-
<P STYLE="margin-bottom: 0cm"> PROCEDURE P* (X:T);</P>
+
-
<P STYLE="margin-bottom: 0cm"> END;</P>
+
-
<P STYLE="margin-bottom: 0cm">ENDM.</P>
+
-
<P STYLE="margin-bottom: 0cm"><BR>
+
-
</P>
+
-
<P STYLE="margin-bottom: 0cm">На первый взгляд это отступление от
+
-
РОРИ. Ибо программисту использующему нужен только интерфейс. На самом
+
-
деле, в к концу 80-началу 90х годов получил распространение приём,
+
-
что язык пишется как часть системы программирования.
+
-
</P>
+
-
<P STYLE="margin-bottom: 0cm"><BR>
+
-
</P>
+
-
<P STYLE="margin-bottom: 0cm">//На 3 этаже стояли перфораторы</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">С этой точки зрения интересен Eifel,
+
-
который генерировал документирующие модули.
+
-
</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; Контрол-Ц &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; IMPORT. Также отсутствует
+
-
понятие главной проргаммы. Считается, что пользователь погружён в ОС,
+
-
и модули экспортируют туда себя. Операционная среда Оберон
+
-
предоставляет шелл, и пользователь может запускать комманды &ndash;
+
-
экспортированные функции.</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">Стиль Си: использование префиксов. Что
+
-
делать если имена конфликтуют имена &ndash; сплошной геморрой.
+
-
Минимум, который необходим &ndash; структуризация модулей, хотя бы
+
-
один уровень.</P>
+
-
<P STYLE="margin-bottom: 0cm"><BR>
+
-
</P>
+
-
<P STYLE="margin-bottom: 0cm">Язык Ада представдяет собой
+
-
ультимативную модель.</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>
+
-
</OL>
+
-
<P STYLE="margin-bottom: 0cm">package M is</P>
+
-
<P STYLE="margin-bottom: 0cm">объявления</P>
+
-
<P STYLE="margin-bottom: 0cm">end M;</P>
+
-
<P STYLE="margin-bottom: 0cm">package body M is</P>
+
-
<P STYLE="margin-bottom: 0cm"><BR>
+
-
</P>
+
-
<P STYLE="margin-bottom: 0cm">end M;</P>
+
-
<P STYLE="margin-bottom: 0cm">Функцию pop на аде написать нельзя,
+
-
потому что у адской функции не должно быть побочного эффекта.</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">Есть пакет STANDART.
+
-
</P>
+
-
<P STYLE="margin-bottom: 0cm">Прространства имён могут вкладываться &ndash;
+
-
коренное отличие от других ЯП.</P>
+
-
<P STYLE="margin-bottom: 0cm">Спецификация пакетов &ndash; неявный
+
-
список экспорта. Доступны они только потенциально.
+
-
</P>
+
-
<P STYLE="margin-bottom: 0cm">Имена пакетов должны быть уникальными.</P>
+
-
<P STYLE="margin-bottom: 0cm">Явной конструкции импорта нет, ибо в
+
-
других ЯП они нужны для раздельной трансляции.
+
-
</P>
+
-
<P STYLE="margin-bottom: 0cm">Синтаксис: P1.P2. ... .PN</P>
+
-
<P STYLE="margin-bottom: 0cm">Интересный вопрос: нужна вложенность
+
-
или нет.</P>
+
-
<P STYLE="margin-bottom: 0cm">В Аде есть такая штука, как перегрузка
+
-
имён и функций, что есть в совр ЯП. Но в Аде можно было также
+
-
перкрывать стандартные процедуры и функции, а акже знаки стандартных
+
-
операций. Беда в том, что стандартные операции не префиксные
+
-
(нектоторые неизвестно какие, например a[i]). Если бы вопрос был
+
-
только о префиксных, то вопрос потенциальной видимости не мешает.
+
-
</P>
+
-
<P STYLE="margin-bottom: 0cm">Пусть есть</P>
+
-
<P STYLE="margin-bottom: 0cm">package Vectors is</P>
+
-
<P STYLE="margin-bottom: 0cm"> type Vector is</P>
+
-
<P STYLE="margin-bottom: 0cm"><BR>
+
-
</P>
+
-
<P STYLE="margin-bottom: 0cm"> function &laquo;+&raquo;(x,y:Vector)
+
-
return Vector;</P>
+
-
<P STYLE="margin-bottom: 0cm">end Vectors;</P>
+
-
<P STYLE="margin-bottom: 0cm"><BR>
+
-
</P>
+
-
<P STYLE="margin-bottom: 0cm">X, Y,Z:Vectors.Vector;</P>
+
-
<P STYLE="margin-bottom: 0cm"><BR>
+
-
</P>
+
-
<P STYLE="margin-bottom: 0cm">X:=Y+z &ndash; нельзя</P>
+
-
<P STYLE="margin-bottom: 0cm">vectors.&laquo;+&raquo;(y,z) &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">Если попытаться на си написать
+
-
A=B*exp(-i*C)*F(x), где всё комплексное, то математик скажет, что это
+
-
не язык. Поэтому Страуструп добавил возможность добавления новых
+
-
операторов.</P>
+
-
<P STYLE="margin-bottom: 0cm"><BR>
+
-
</P>
+
-
<P STYLE="margin-bottom: 0cm">И возникает вопрос, зачем тогда
+
-
переопределение операторов если нет непоср области видимости? Поэтому
+
-
в Аду есть uses список пакетов. Тогда можно для векторов писать
+
-
Z:=X+Y. На первый взгляд всё замечательно. Но что делать, если
+
-
возникате конфликт имён? Если X оперделён глобально, в M1, M2. И это
+
-
приводит к программам, смысл которых от uses меняектся.</P>
+
-
<P STYLE="margin-bottom: 0cm"><BR>
+
-
</P>
+
-
<P STYLE="margin-bottom: 0cm">Проектирование систем:</P>
+
-
<P STYLE="margin-bottom: 0cm">top-down</P>
+
-
<P STYLE="margin-bottom: 0cm">bottom-up</P>
+
-
<P STYLE="margin-bottom: 0cm">Системы разбиваются на набор модулей,
+
-
вопрос в том, с каком порядке разбивать.</P>
+
-
<OL>
+
-
<LI><P STYLE="margin-bottom: 0cm">Сверху вниз: разбить систему на
+
-
модули, эти модули на ещё модули и т. д. Проблема в том, что делают
+
-
заглушки. И тут мы тренируемся на лягушатнике, а когда бросают в
+
-
бассейн &ndash; буль-буль</P>
+
-
<LI><P STYLE="margin-bottom: 0cm">Снизу вверх. Модули нижнего уровня
+
-
отлаживаются проще. Недостаток: заказчик не знает, что хочет, и
+
-
меняет заказ, и видит готовую систему в самый последний момент.</P>
+
-
</OL>
+
-
 
+
-
{{Языки Программирования}}
+

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


Отменить | Справка по редактированию (в новом окне)

Шаблоны, использованные на этой странице:

Получено с http://esyr.org/wiki/%D0%AF%D0%B7%D1%8B%D0%BA%D0%B8_%D0%BF%D1%80%D0%BE%D0%B3%D1%80%D0%B0%D0%BC%D0%BC%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D1%8F%2C_16_%D0%BB%D0%B5%D0%BA%D1%86%D0%B8%D1%8F_%28%D0%BE%D1%82_26_%D0%BE%D0%BA%D1%82%D1%8F%D0%B1%D1%80%D1%8F%29
Личные инструменты
Разделы