На прошлой лекции мы начали рассматривать тип данных указатели/ссылки. На этой лекции мы продолжим рассмотрение этого типа данных и рассмотрим функциональный тип данных.

Две основные проблемы, которые связаны с типом данных указатели, связаны с тем, что обычно указатель используется для ссылок на динамические структуры данных, которые расположены в динамической памяти. По крайней мере, в строгих языках программирования, к которым с этой точки зрения относятся стандарт Паскаль, Ада 83, Оберон, с одной стороны, есть понятие указателя, а с другой стороны это понятие указателя, особенно в Аде 83, ограничено таким образом, что указатели ссылаются только на объекты из динамической памяти. Для таких указателей мы отметили две главные проблемы:

1. Мусор

2. Висячие ссылки.

В языках, где есть динамическая сборка мусора, а из этих языков она есть только у языка Оберон, динамическая сборка мусора полностью решает проблему мусора и проблему висячих ссылок за счет проблем с эффективностью. Причем, самое неприятное обстоятельство, связанное с динамической сборкой мусора это то, что память освобождается из-под объекта, не по команде программиста, а в произвольный момент времени, который выбирает сам динамический менеджер памяти. Есть несколько версий решения этой проблемы: первая - это стремительно нарастающее быстродействие компьютера, вторая - улучшающийся алгоритм сборки мусора. Существуют, также, другие версии решения этой проблемы. Введение в методы реализации динамической сборки мусора есть в книге Себесты.

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

Кроме этого здесь есть еще один аспект. Многие версии Паскаля, прежде всего Турбо Паскаль, Delphi, как наследник Турбо Паскаля и, конечно же, такие языки как С и С++ - это языки нестрогие в том плане, что там понятие указатель расширено, а именно: указатель – это не только ссылка на объект динамической памяти, в этих языках есть понятие адресной операции, которая выглядит в С - &, в Delphi - @. Т. е. можно взять адрес произвольного объекта и присвоить его указателю. В результате никакой видимой разницы между двумя типами указателей нет. И в таких языках, наряду с этими двумя проблемами появляются проблемы, связанные с тем, что мы можем пользоваться указателем, например на автоматический, то есть квазистатический объект, размещаемый в стеке, мы уже покинули соответствующий блок, а указатель продолжает существовать. Эта проблема очень похожа на проблему висячей ссылки, т. е. указатель у нас определен, куда-то указывает, но про содержимое этой области памяти мы ничего сказать уже не можем потому, что она освобождена. Т. е. это проблема, связанная с висячей ссылкой, но которая получается за счет того, что мы можем брать любой объект памяти, в том числе и статический. Кроме этого появляется проблема ошибочного освобождения памяти, т. е. мы освобождаем указатель, который на самом деле указывает не на динамический объект.

Эти ошибки очень опасны, потому что они проявляются совершенно не там, где их ждешь, и поэтому их устранение очень накладно. И поэтому во многих языках, прежде всего в этих строгих, отказались от идеи того, что указатель указывает на произвольный объект. Например в Аде 83, как уже говорилось, единственная возможность проинициализировать указатель – с помощью операции new T, ну и, разумеется, операции присваивания :=. Если реализация Ады позволяла динамическую сборку мусора, то тогда соответствующее решение было весьма и весьма надежным. Но с одной стороны, как уже говорилось, реализация Ады допускает и нединамическую сборку мусора, а с другой стороны ситуация в 90-ых годах несколько изменилась. И интересно, что в Аде 95 создатели языка были вынуждены расширить язык таким образом, чтобы допустить указатели и на нединамические объекты. Спрашивается: зачем, ведь, как мы выяснили, это еще более добавляет ненадежности в указатель, а указатель – это самый ненадежный простой базисный тип данных в ЯП. Что изменилось с 1983 года? Подходы к надежности – нет, Ада 95 с точки зрения надежности исповедывала те же критерии, что и предыдущий стандарт языка – Ада 83. Изменились внешние условия: если создатели Ада 83 были уверены, что они проектируют единый универсальный ЯП, который должен заменить все существовавшие к тому времени в соответствующей проблемной области языки программирования. Ситуация в 95-м году понятно была какой – было ясно, что новый стандарт Ада не может претендовать на роль всеобъемлющего ЯП. В результате связь программ на языке Ада с программами на других языках из чисто опционального (какого-то дополнительного) средства, как это было в момент создания первого стандарта Ада, превратился в насущную необходимость. Для чего нужны указатели на нединамические объекты? Прежде всего, чтобы можно было вызывать программы на других ЯП и соблюдать соглашения о вызовах, соглашения о типах параметров, которые приняты для тех ЯП. Чаще всего вызываются программы, написанные на С, на Фортране. Для вычислительных программ – подпрограммы на Фортране, для системных программ - это интерфейсы на С или С++, а в этих языках все системные интерфейсы разработаны так, что без указателей там не обойтись. Cпрашивается: можно ли попытаться сохранить достаточно надежным язык? Создатели Ада 95, за счет, естественно, некоторого усложнения языка наши достаточно приемлемое решение для сохранения надежности. Новые проблемы возникли с тем, что, скажем, в том же самом С++, внешне никак нельзя отличить указатель, размещенный с помощью процедуры new от указателя, который мы получили с помощью адресной операции. Вот от этого свойства указателей и надо отказаться. В языке Ада есть обычный указательный тип а-ля Ада 83

Type PT is access T;

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

X1:PT;

то в этом случае мы можем размещать X1 с помощью оператора new, который вызывает менеджер динамической памяти.

X1:=new T;

Эти указатели в языке Ада 95 остались. Но появился еще новый указательный тип, а именно

Type PTT is access all T;

Это означает, что указатели PTT могут ссылаться как на динамические объекты, так и на нединамические. Если мы опишем переменную

X2:PTT;

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

X2:=new T;

Но кроме этого можно еще адресовать и объекты из нединамической памяти, но не любые объекты, а только те, которые специально для этого предназначены. Пусть у нас есть какая-то переменная

Y1:T;

и переменная Y2, которая описана с помощью ключевого слова aliased

Y2:aliased T;

И то и то относится к одному и томуже типу данных, однако ключевое слово aliased говорит о том, что дополнительно к числу операций, которые можно проводить над типом T добавляется еще операция вычисления адреса, а именно допустима конструкция

X2:=Y2'access;

Мы получили в Х2 адрес переменной Y2. При этом соответствующий указатель должен быть объявлен с атрибутом all.

X1:=Y2'access;

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

X2:=Y1'access;

ошибка, связанная с тем, что указатель Х2 относится к типу PTT, но, однако, к Y1 не применима операция access. В результате проблемы, о которых говорилось ранее, здесь снимаются. И в результате можно передавать и адреса нединамических объектов, скажем функций, написанных на языке С. Это скорее всего будут системные вызовы из соответствующей библиотеки, или из интерфейса прикладного программиста API. Поэтому эта проблема, разумеется, снялась. И это, конечно, достаточно неплохое решение.

Еще в языках основанных на С, на С++ есть понятие адресной арифметики, которая, во общем-то приводит к тому, что надежность соответствующих языков вызывает очень и очень большие сомнения.

В более строгих языках, чем С и С++ операции над указателями фактически ограничены следующим образом: во-первых операция присваивания := , кроме этого операция размещения в динамической памяти new, ну и еще в языке Ада для некоторого вида указателей адресная операция access, но адресная операция, которая защищена с помощью соответствующих конструкций. И если в языке реализована динамическая сборка мусора, то есть у нас отсутствует оператор типа delete, то решение с указателем получается вполне надежным. То есть никаких проблем с указателем, о которых мы говорили, у нас нет. И поэтому если мы определим указатели таким образом, что крайне ограничим им набор операций: только присваивание и только выделение динамической памяти и больше никаких других операций (ну и естественно передача как параметр, что эквивалентно присваиванию) то получившаяся конструкция указателя становится вполне надежной. Но только ее уже не надо называть указателем, потому что слово указатель в определенного рода кругах вызывает недоверие. И, следовательно, тогда такой ограниченный тип данных с точки зрения множества значений все равно остается адресом, и имеет смысл переименовать его в такой тип данных, как ссылка. И действительно, в современных языках программирования происходит интересный процесс, а именно: у нас появляется новый ссылочный тип данных. Это языки Delphi, Java и C#. В Java, например, все типы данных делятся на:

а) простые типы данных, которые мы уже рассматривали. Это, прежде всего, арифметические, логические, символьные и т. д..

б) ссылочные типы данных, к которым относятся массивы, классы и интерфейсы. И все эти данные описываются с помощью ссылок.

Та же самая ситуация и в языке Delphi. Там есть понятие класса – новое понятие. Так вот объекты классов в языке Delphi это исключительно ссылки и то же самое относится и к С#. Но по сравнению с Java, Delphi и C# несколько перенавороченны, а именно: в Delphi есть еще старое понятие записи, унаследованное из Турбо Паскаля, а в C# есть еще понятие структуры, которое похоже на урезанный класс. Когда мы будем говорить о составных типах данных, мы поговорим о структурах языка C#. Но в целом, именно основные типы данных, выражаемых классом, в этих языках выражаются с помощью ссылок.

Рассмотрим размещение переменной. Пусть у нас есть класс Х. Мы объявляем объект х класса Х

Х х;

В принципе это объявление синтаксически верно и на языке Java, и на языке C++, и на языке C#. Но на языке С++ это значит совершенно другое, а именно то, что в С++ объект соответствующего типа данных размещается в памяти, в какой - это зависит от того где находится это объявление: либо в квазистатической памяти, если оно находится, например, внутри блока, либо в статической памяти, если оно объявлено она верхнем уровне. Если же речь идет об объявлении в С# или Java, то это на самом деле размещается только ссылка на объект класса Х. То есть, везде, где речь идет об именах объектов, нужно понимать, что это ссылки, причем то же самое относится и к массивам. Например, в Java

char a[];

Причем в Java, как и в C# запрещено даже указывать здесь длину массива. Здесь речь идет не о том, что размещается какой-то массив в памяти, а размещается просто ссылка на соответствующий массив. При этом в начальный момент времени они никуда не указывают.

х

а

Соответствующие объекты должны быть обязательно проинициализированы с помощью оператора new.

х= new X;

a= new char[20];

И менно в момент выполнения операции new происходит инициализация ссылки на соответствующий объект

х Х