Лекции (1129116), страница 21

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

Текст из файла (страница 21)

Каждый файл указывает, к какому пакету он относится. Пакет служит единицей контекста. Он состоит, как правило, из нескольких файлов в одной директории. То есть, если проект состоит из нескольких директорий, то, скорее всего, он состоит из нескольких пакетов.

Учитывая то, что все современные ОС имеют иерархические файловые системы, то естественно предполагать, что у Java машины будет аналогичная файловая система:

package name1.name2.name3. …

То есть это совопкупность имен разделенных точкой. Как правило, у каждой Java системы есть корневая директория, от которой растут эти имена. В распределенных файловых системах путь может предваряться URL:

имя_домена1.имя_домена2. …

например, cs.msu.su

Когда мы импортируем какой-то пакет, то должны написать, например:

import java.lang.*

- это импорт не отдельных классов, не единиц компиляции, а целых пакетов.

По импорту мы получаем то, что объявлено как public, то есть интефейс классов. То, что private и protected не доступны за исключением функций-членов.

Для того, чтобы сделать класс доступным по import, мы должны объявлять его как public.

Трансляционная библиотека в Java состоит только из public имен. В силу специфики Java можно импортировать пакеты откуда угодно по URL. И вытекающая отсюда идея о распределенной системе программирования очень красива.

Довольно тесно с трансляцией связано понятие инициализации модулей и соответствующего порядка. Много здесь говорить не следует, но некоторые аспекты упомянуть надо.

Пусть у нас есть:

with M

package M1 is

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

M1 => M2 => M3 => M1

В данном случае невозможно понять, с какой точки инициализировать. Программист должен очень внимательно следить за использованием операции контекста.

Где возникает это зацикливание в определениях или реализациях? Очевидно, что в определениях. В реализациях зацикливание не страшно. Посмотрим пример на Delphi:

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

Зацикливание по определениям выдаст ошибку, так как транслятор не сможет понять, что обрабатывать в первую очередь.

На этом мы закончим тему, связанную с раздельной трансляцией.

Лекция 17

Глава 7. Статическая параметризация.

Из рассматриваемых нами языков, статическая параметризация реализована в двух языках, а именно, в Аде и С++. При этом, механизм статической параметризации в С++ сильнее, и следовательно, сложнее.

Откуда возникает необходимость в статической параметризации? Прежде всего, это нужно для контейнеров, которые мы уже немного рассматривали.

class Stack{

}

При описании стека у нас есть альтернатива: либо мы сразу описываем его величину (тогда стек фиксирован), либо использовать стек в динамической памяти (тогда возникает параметрический конструктор, например конструктор преобразования, если не хотим его делать конструктором преобразования, то нужно использовать ключевое слово explicit).

В языке Ада тоже есть возможность параметризации:

type Stack(size:integer:=20) is record

Body : array(1..size) of integer;

Top : integer:=1;

end record;

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

Каким образом в традиционных языках программирования решают эту проблему? Известно, что наиболее общий тип данных – это void* в Си, ADDRESS в МОДУЛЕ-2, и т.д. Этот тип всегда может быть преобразован к указателю на любой другой тип. И мы можем, помещая объект в стек, сами делать привидение типов:

X=(void*)S.Pop();

S.Push((void*)X);

Примерно такая же дыра в системе типов есть и в Аде. Эта дыра сознательно остается в языке, как единственная возможность параметризации по типу. Разумеется, при этом теряется надежность. Поэтому создатели языка Ада, чтобы не провоцировать программиста к появлению такого рода конструкций, ввели понятие статической параметризации. Здесь речь идет о параметрах двух типов: нужен целый параметр, который регулирует размер стека, и, самое главное, нужно параметризовать тип. И если параметризация размеров выполняется достаточно легко, то параметризация типов – дело непростое. Речь идет о статической параметризации типов, прежде всего, потому что динамическая параметризация очень сложна.

Для того, чтобы обеспечить надежность, необходимо чтобы компилятор смог проконтролировать динамически информацию о типе, т.е. необходима система динамической идентификации типа RTTI (Run Time Type Identification). Типы данных содержат очень много информации, и "тащить" эту информацию динамически очень накладно. Еще более накладно проверять эту информацию во время выполнения программы. Поэтому традиционные языки программирования не используют (или почти не используют) средств динамической параметризации типов. С объектно-ориентированными языками ситуация другая. И в С++, и в Java, и в Delphi, уже есть система RTTI, поэтому, в принципе, теоретически возможна динамическая параметризация типов. Однако более эффективна статическая параметризация, когда всю настройку проводит компилятор. Рассмотрим, что представляет собой статическая параметризация в языках Ада и С++.

Язык Ада.

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

generic

[список_статических_параметров]

спецификация_родового_сегмента // спецификация пакета, либо тело подпрограммы

Механизм статической параметризации в Аде формировался на основе следующих требований к языку:

1. Раздельная компиляция. Это наиболее жесткое требование. Родовые сегменты должны удовлетворять тем же правилам раздельной компиляции, что и обычные пакеты и подпрограммы, т.е. должна быть возможность раздельной компиляции спецификации родового сегмента и реализации.

2. Надежность. В условиях раздельной компиляции, компилятор должен обеспечить такую же строгость проверки типов, что и для обычных сегментов.

3. Разделение спецификации, реализации, использования. Спецификация, реализация и порождение нового пакета или подпрограммы могут быть разделены и оттранслированы по отдельности.

Рассмотрим на примере, что представляет собой родовой модуль. Для начала, рассмотрим пример, в котором список параметров вообще отсутствует. Как ни странно, но в этом есть смысл. Рассмотрим (пока не родовой) пакет Stack, но который инкапсулирует в себе не тип данных, а один объект.

package Stack is

procedure Push(X:T); // тип Т должен быть ранее определен и виден в этой точке

function Pop() return T;

….

end Stack;

Эта спецификация очень напоминает спецификацию класса. Когда мы делали класс Stack то в функцию Рор() нужно было передавать объект типа Stack (как in-out) и в функции его модифицировать, а в Аде такая побочная модификация запрещена. Здесь параметр отсутствует, потому что этот параметр помещен внутрь реализации. Пакет – это достаточно общая структура, которая необязательно используется только для определения новых типов, но и для определения некоторых бестиповых объектов (как в данном случае). Как сделать несколько разных стеков с помощью этой структуры? Для этого необходимо превратить этот модуль в родовой сегмент с помощью слова generic.

generic

package Stack is

procedure Push(X:T);

function Pop() return T;

….

end Stack;

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

package Stack1 is new Stack;

Stack1.Push(x);

Y=Stack1.Pop();

Таким образом, с помощью механизма родовых сегментов можно описывать структуры, которые очень похожи на классы.

Теперь давайте рассмотрим более общий пример. Попытаемся сделать тип данных стек с некоторой параметризацией по типу:

generic

type T is private; // Т - неизвестно какой тип, допустимы только операции

package Stack is // присваивания и передачи как параметр

size : integer;

… // описываем структуру стека

end Stack;

Здесь приватность типа Т означает только то, что мы об этом типе ничего не знаем. Как использовать такие стеки?

package INT_Stack is new Stack(integer,20);

INT_Stack.Push(1);

Аналогично можно описывать стеки других типов. В принципе, мы можем написать в более классическом варианте, не порождая другие модули, а написав тип Stack так, чтобы он был действительно абстрактным типом данных:

package Stacks is

type Stack is private

procedure Push(S:inout Stack; X:T);

…

private

type Stack is record … end record; // здесь описываем тело стека

end Stacks;

package INT_Stacks is new Stacks(integer,45);

S : INT_Stacks.Stack;

INT_Stacks.Push(S,1);

С подобными модулями можно использовать слово use. Если мы аналогично опишем модуль CHAR_Stacks, то можно писать так:

use INT_Stack, CHAR_Stack;

S : CHAR_Stacks.Stack; // здесь необходимо указать имя модуля

Push(S1,'A'); // а здесь компилятор сам разберется по типу первого параметра

Push(S,1); // т.е. работает механизм перекрытия

В предыдущем примере так делать было нельзя.

Подпрограммы тоже можно статически параметризовать. Рассмотрим пример процедуры сортировки массива.

type ARR is array(INDEX range<>) of T;

procedure SORT(A: inout ARR);

Если мы работаем с массивом, у которого другой тип индекса (наследник целого типа), то тогда нельзя сортировать такие массивы. Здесь можно сортировать только массивы типа Т. Для сортировки массивов другого типа необходимо писать свои процедуры. При этом тела соответствующих процедур будут различаться только типами элементов массива. Это как раз тот случай, когда нужно использовать статическую параметризацию. Каким образом нужно описать формальные статические параметры для процедуры сортировки? Что с собой нужно "тащить"? Хочется параметризовать тип Т, и хочется параметризовать тип индекса.

generic

type INDEX is range <>; // здесь нельзя написать private, потому что это произвольный

// тип данных, а нам нужен дискретный., поэтому мы указали range

type T is private;

type ARR is array (INDEX range <>) of T; // мы должны еще параметризовать массив, потому что

// в процедуре SORT можно только указать имя конкретного типа.

with function "<" (x,y:T) return BOOLEAN; // нужно передавать и операцию сравнения,

// потому что она не определена для private-типа

procedure SORT(A: inout ARR);

Мы были вынуждены описывать четыре параметра, для того, чтобы компилятор смог проконтролировать совместимость типов. Как же использовать эту абстракцию?

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

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