лекция 17 (1161112)

Просмтор этого файла доступен только зарегистрированным пользователям. Но у нас супер быстрая регистрация: достаточно только электронной почты!

Текст из файла

Языки программирования.

Лекция 17.

Раздельная трансляция (Продолжение).

В прошлый раз мы закончили рассматривать раздельную компиляцию на довольно современных яп – Си#, Java. Подход этих языков очень близок, основан на том, что классическое различие между трансляционной библиотекой и программной библиотекой теряется. Поскольку, мы отмечали, что в современных яп, оттранслированный текст (сборки в Си# и классы в Java) содержит в себе всю необходимую информацию, которая нужна как для исполнения кода, так и для контроля интерфейса, таблицы имен и т.д. (для того, что обычно лежало в трансляционной библиотеке). Соответствующие средства для подключения контекста и прочего существенно упрощаются, есть специальные конструкции

Например, для Java:

import полное_имя_класса

import полное_имя_класса:*

полное_имя_класса = полное_имя_пакета.имя_класса

эти конструкции нужны только для того, чтобы снять потенциальную видимость. поскольку у нас есть конструкция пакет и при этом каждый файл языка Java должен начинаться с конструкции package имя_пакета. В Java (и в Си#) единицей компиляции является файл. В Java в одном файле содержится один или несколько классов.

По какому принципу разбрасывают классы по файлам – однозначного ответа нет, но есть разнообразные намеки (рассматриваем одновременно Си# и Java):

1. В Java существует некий главный класс (некий публичный класс, выходящий за пределы пакета), такой:

public имя_класса {

public static int main(String []args) {...} - главная функция

}

В Java 2 требуется, чтобы такой главный класс был один в соответствующем файле, и имя класса является в некотором смысле именем исполняемой программы.

1. Рекомендация для Java (и для Си# - может по умолчанию предлагаться интегрированной средой) - в одном файле не более одного класса. Но каждый класс должен приписать себя к какому-нибудь пакету (пространству имен – для Си#).

1. Java

Конструкция файлов на языке Ява:

Первой строчкой должно быть: package имя_пакета – т.е. класс приписывает себя к соответствующему пакету. Файлы пакета должны принадлежать одной директории. Структура пакетов имеет древовидную структуру. Полное имя пакета аналогично полному имени файлов в древовидной иерархической структуре. Все файлы пакетов образуют древовидную структуру, которая адресуется с помощью универсального локатора ресурсов (url), который может адресовать файл как в данной локальной файловой системе, так и где-то в пределах сети. Откуда начинается это дерево? Предполагается, что в каждой реализации есть специальная переменная CLASSPATH, и именно она определяет имя директории, в которой лежат файлы пакета. Когда мы пишем import имя_пакета, например P1.P2.P3, то компилятор смотрит CLASSPATH находит поддиректорию Р1, в ней Р2, в ней Р3. В Р3 должны находиться все классы относящиеся к соответствующему пакету. Так у нас иерархическая структура пакета соотносится с иерархической структурой файловой системы при этом ничего общего с вложением пакетов языка Ада здесь нет (см. предыдущие лекции). Если в языке Ада один пакет вложен в другой (например, Р2 вложен в Р1) – это означает, что

1. спецификация пакета Р2 имеет полный доступ ко всем именам, описанным в Р1

2. тело пакета Р2 может ссылаться на переменный описанные внутри тела пакета Р1

Получается, что в Аде пакеты Р1 и Р2 зависят друг от друга.

В Java зависимость только внешняя, никакой реальной зависимости нет. То, что пакет Р2 вложен в пакет Р1, это совсем не означает, что Р2 имеет доступ к внутренним классам (имеются ввиду классы видимые в пакете, для Си# - внутренний доступ) Р1, и наоборот. Вложенность – просто способ расположения пакетов. Реально в Яве используется линейное распределение пакетов. А древовидная организация нужна для того, чтобы местоположение пакета можно было бы найти не только в данном компьютере, но и в сети.

В результате конструкции import являются исключительно вспомогательными (мы всё ещё можем обращаться к пакетам через полные имена) – для компилятора это загрузка классов из соответствующего пакета. Нам доступен любой публичный класс из иерархии пакетов, мы должны указать путь к нему – полный_путь_пакет.имя_класса, так можно сделать и внутри программы. Import становится совершенно необязательно, так происходит в первую очередь потому, у нас независимость трансляционной библиотеки от программной. Правда, необходимо, чтобы соответствующий класс был оттранслирован, такие зависимости обычно регулируются интегрируемыми средами внутри языков.

2.Си#

В языке Си# ситуация похожа. Пространства имён очень похожи на пакеты, но здесь ситуация с вложенностью немного более хитрая. Единица компиляции - это файл (так же как и в Java). Файл может содержать один или несколько классов, в зависимости от типа приложения. Если приложение консольное, то у него должен существовать один публичный класс, в котором должна существовать публичная статическая функция main (синтаксис и семантика такая же как в Java). Приложения бывают самые разные, у каждого свои требования к организации пространства имен. Исполняемый файл (сборка), как правило, носит имя, которое носит самое внешнее объемлющее пространство имён.

Каждый класс должен находиться исключительно в каком-то пространстве имён namespace:

namespace имя {

определение классов, интерфейсов,

перечисления // ничего другого в программе на Си# быть не может

};

Ситуация очень похожа на пространство имен в языке Си++. Пространство имен Си# (также как и пакеты) открыто снизу. Это означает, что любой новый файл может приписать себя к произвольному пространству имен. В отличие от Java в Си# нет привязки к иерархической файловой системе. Есть стандартные пространства имен, например System, XML. Мы можем средствами независящими от языка добавить свои пространства имён. С точки зрения реализации пространство имён - транслированный текст на языке Си#. Когда мы добавляем свое пространство имен – это обозначает, что у нас появился файл на Си#, который приписал себя к конкретному пространству имени. Пространства имен каким-то образом привязаны к файловой системе, это делается средствами не зависящими от языка, а зависящими от средств программирования (итог: главное, чтобы каждый файл приписать себя к некоторому пространству имен, как привязываются пространство к файловой системе нас в данный момент не интересует).

В отличие от языка Java, где пакеты независимы друг от друга, пространства имён ведёт себя так же, как в языке Ада.

namespace N1 {

class C1 {...};

public class C2 {...}

namespace N2{

...// в данной точке имеем доступ не только к С2, но и к С1

};

};

Пространства имен действительно являются структурированными. Можем написать такой пример:

MyProject // объемлющее пространство имен

namespace MyProject.Exceptions {

...

};

Общий случай синтаксиса пространства имен:

namespace N1.N2. ... .Nk {

...

}

Это действительно пространства имен, которые вкладываются друг в друга, то как они отображаются в виде оттранслированных файлов на файловую систему – это другой вопрос, и это определяется средствами среды программирования. Во всех предыдущих языках мы четко разделяли уровень хранения файлов (то, как хранятся файлы в проекте) и уровень организации файлов внутри проекта (замечание: о том, по каким директориям хранятся файлы, например, в проекте на языке Ада мы вообще не говорили – такие вещи не относятся к собственно языку).

Если мы не используем вложенные пространства имён, то этот поход становится похожим на подход языка Java. Как использовать пространство имен? Рассмотрим пример:

System.Console.Writeln() // напишем внутри программы

У нас есть пространство имен System, внутри него есть класс Console и у класса есть статическая функция, которая называется Writeln().

Внутри пространства имён все имена доступны непосредственно. А снаружи можно обращаться через оператор ".":

N1.C2

N1.С1 // не можем, так как приватный доступ

N1.N2.C3 (см. пример выше)

Отметим, что мы не используем объявление импорта, все доступно через полное объявление.

Если нас утомляет каждый раз писать весь путь, то можно просто написать:

using System; // все имена из пространства имен System являются доступными

using System.Graphics;

Это тоже самое, что импорт из имя_пакета*, все имена из пространства имен становятся видимыми непосредственно, за исключением тех случаев, когда имена начинают конфликтовать. Все стандартные пространства имен в .Net Framework подобраны так, чтобы имена между собой не конфликтовали.

Можно вводить синонимы:

using имя = имя1.имя2.имя3...; // так как в реальных проектах часто встречается некоторая вложенность. Причем такую конструкцию удобно использовать, когда может возникнуть конфликт имен – а прописывать весь адрес через вложенные пакеты долго и неудобно, а так адрес станет короче для написания.

Заканчивая разговор о раздельной компиляции, заметим, что изначально большое внимание уделялось межмодульным связям и проблемам перекомпиляции всей программы (машинное время стоило дорого, а перекомпиляция – достаточно долгая). В современных яп вычислительная мощность хост-систем, на которых осуществляется трансляция, достаточна высока, и скорость перетрансляции всего проекта совершенна не критична.

Глава 7: Исключительные ситуации

Мы различаем нормальное выполнение и ненормальное выполнение (когда что-нибудь происходит).

В ранних ЯП (например, PL-1, Basic) синтаксис:

ON ситуация оператор //(например, деление на ноль)

Такая on-ситуация устанавливала наблюдатель ситуации, как только возникала ситуация, то выполнялся оператор. Чаще всего был оператор перехода на обработчик исключительной ситуации. Чаще всего обработчики использовались на ситуации ENDFILE (хотя это не совсем так исключительная ситуация, о которой стоит говорить, вот если бы конца файла не было ), в этом случае оператор перехода - это выход из цикла чтения из файла. Такие операторы были похожи на системные прерывания.

В современных ЯП исключительная ситуация – авария, и в других целях лучше её не использовать. Исключительная ситуация - сигнал о какой-то ошибке. Есть 2 подхода к проектированию "безошибочных" (надёжных) систем (которая функционирует всегда, независимо от того в каких условиях ей придется работать). Что такое абсолютно надежная программа, можно по пробовать дать математическое определение. Рассмотрим постусловие Дейкстры: есть предусловия Р1 и постусловие Р2, и есть некоторая программа. Если мы докажем, что если задано условие Р1, то мы всегда можем доказать, что по тексты программы из предусловия Р1 получается постусловие Р2. Тем самым мы математически доказываем, что относительно данных пред и пост условий программа работает совершенно корректно.

• Математический и академический подход.

Математический подход - мы должны сформулировать начальное и конечное условия и доказать правильность работы программы.

С таким подходом возникает множество проблем, например спецификация начальных и конечных условий. Часто и формальная спецификация ввода и вывода, и доказательство корректности весьма сложные задачи. Как определить, что доказательство верно?

• Инженерный подход.

Инженерный подход - это искусство построение надёжных программ из ненадёжных компонент - мы не доверяем никому и предполагаем, что любое условие может быть нарушено. Механизм исключительных ситуаций должен предоставлять априорные средства управления.

Классическая техника обработки ошибок (рассмотрим на примере Си):

Каждый системный вызов имеет прототип:

int имя (параметры) // обычно имеет место результат < 0 – ошибка

Как только может что-то произойти, то мы в программе на Си пишем примерно так:

if (...) { // проверяем

... // исправляем

} else {

...

}

В такой программе нормальный ход выполнения и собственно код, который обрабатывает ошибки, переплетены между собой, что весьма неудобно. Механизм обработки ситуаций, чтобы быть управляемым и контролируемым, должен поддерживать принцип разделяемости (тут код для нормально ситуации, тут для исправления ошибок). Причем часто реакция на ошибку находится совсем в другом месте относительно возникновения ошибки. Как правило, исключения возникают намного ниже того места, где они должны обрабатываться, поэтому эта ошибка должна всплыть.

Впервые современная модель появилась в языке Ада. Но современные ЯП так или иначе используют модель языка Си++.

Определение 1: Исключительная ситуация - авария.

Определении 2: 4 аспекта обработки исключительных ситуаций (ИС):

1. Определение ИС;

2. Возникновение ИС;

3. Распределение ИС;

4. Обработка ИС.

Целью работы с ИС является то, что система должна всегда поддерживать свою работоспособность.

В Модула 2, Оберон поддержки обработки исключительных ситуаций нет.

1.Ада

Характеристики

Тип файла документ

Документы такого типа открываются такими программами, как Microsoft Office Word на компьютерах Windows, Apple Pages на компьютерах Mac, Open Office - бесплатная альтернатива на различных платформах, в том числе Linux. Наиболее простым и современным решением будут Google документы, так как открываются онлайн без скачивания прямо в браузере на любой платформе. Существуют российские качественные аналоги, например от Яндекса.

Будьте внимательны на мобильных устройствах, так как там используются упрощённый функционал даже в официальном приложении от Microsoft, поэтому для просмотра скачивайте PDF-версию. А если нужно редактировать файл, то используйте оригинальный файл.

Файлы такого типа обычно разбиты на страницы, а текст может быть форматированным (жирный, курсив, выбор шрифта, таблицы и т.п.), а также в него можно добавлять изображения. Формат идеально подходит для рефератов, докладов и РПЗ курсовых проектов, которые необходимо распечатать. Кстати перед печатью также сохраняйте файл в PDF, так как принтер может начудить со шрифтами.

Список файлов лекций