Лекция №4

Прошлый раз закончили на рассмотрение концептуальных схем развития ЯП, напомним их:

скалярный

1. Б азис структурный

2. Средства развития

3. Средства защиты

Начнем рассматривать более детально ЯП. Сегодня начнем смотреть наиболее большую по объему первую часть.

Традиционные языки программирования.

Здесь будем говорить не про Алгол, Фортран PLI Кобол или Паскаль, а про более современные ЯП. Сейчас появляются, развиваются и наиболее широкое распространение получили языки, которые поддерживают объектно-ориентированную парадигму программирования , при этом все они являются лишь обобщением традиционных ЯП, основанных на императивной парадигме программирования. Т. е. наиболее главным понятием является понятие переменной, где хранится некоторая информация, базовый оператор -- это оператор присваивания, которые меняет состояние этих переменных.

Глава 1. Базисные типы данных.

П.1.1 Скалярные (элементарные) типы данных.

целые

арифметические вещественные

символьные

скалярные логические

типы перечислимые

данных порядковые диапазонные

ссылки и указатели (рассматриваются отдельно)

Эти типы данных образуют скалярный тип данных практически всех современных ЯП.

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

1. Представление

2. Без знаковость

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

char char

short short

=======> unsigned {

int int

long long

Зачем нужен без знаковый тип? От куда они появились изначально? Можно было просто реализовать тип данных целые и работать с одним типом данных, так как без знаковый тип является подмножеством более общего понятия целого числа. Точно так же как в математике целые числа являются подтипом более общего понятия – вещественное число. Тем не менее вещественные числа в архитектуре очень сильно отличаются от целых и их выделяют в отдельный тип данных. Без знаковый тип данных появился по нескольким причинам:

1. Технологическая. С точки зрения языка Ассемблера работа с адресами очень важна, а адрес – это беззнаковое целое.

2. Разрядность слова – величина ограниченная, и возможность представления числа в два раза больше иногда очень полезна.

Если мы рассмотрим 16-ти битные архитектуры, которые были популярны в 70-е – 80-е годы, то диапазон неотрицательных чисел, если рассматривать их как знаковые 0 .. 32767, что мало, а если рассматривать как без знаковые, то это в два раза больше, что сыграло существенную роль. Сейчас, когда все больше начинают доминировать 32-битные архитектуры, необходимость в беззнаковости отпадает. Иногда отсутствие беззнакового типа порождает ошибки, когда мы начинаем смешивать знаковые и беззнаковые типы данных. В современных ЯП наблюдается последовательный отказ от без знакового типа данных. В языка Модула-2, который первоначально был реализован на 16-ти битной архитектуре, присутствовал без знаковый тип данных. В следующим за ним, который построил Вирт, Оберон, основанный на принципе минимализма, не имеет без знакового типа данных. По этому же пути пошли создатели языка JAVA, там есть только знаковые типа данных: byte, short, int, long. Char тоже там есть, но он не рассматривается как арифметический тип данных. За счет этого упростилась структура JVM, упростился интерпретатор. На производительности это никак не отобразилось. Но в некоторых языках осталась тенденция реализовывать все существующие типы данных, например Delphi, С# содержат все типы данных, которые можно придумать. В С#:

sbyte byte

short ushort

int uint

long ulong

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

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

Представление. Как известно, стандартный Паскаль, С не фиксирует представление целых типов, например, ничего нельзя сказать про размер типа данных int. Это сделано для того чтобы обеспечить лучшую переносимость программ и производительность. Язык JAVA, который разрабатывался как универсальный язык для программирования в разных средах (девиз JAVA WORE – пишешь один раз, выполняешь где хочешь), его разработчики гнались не столько за эффективностью сколько за переносимостью. Именно поэтому они выкинули беззнаковые типы данных и фиксировали сразу представление всех типов данных. В Delphi представление типов данных тоже фиксировано, потому что изначально этот ЯП предназначался только для Windows. В С# тоже зафиксировано представление, потому что объявлено, что С# как и среда .NET объявлены переносимыми на любую архитектуру.

Интересно посмотреть, как эти проблемы решались в языке Ада. Компилятор решает, как высокоуровневые концепции отобразить на соответствующую архитектуру. Считается, что есть тип данных integer, представление которого не фиксируется. Здесь очень интересна концепция производных типов. Если нам нужен без знаковый тип, то мы пишем:

type NATURAL range is new INTEGER 0..65535

Такое объявление говорит, что у нас появился новый тип данных, который наследует вс6е свойства типа данных INTEGER, за исключением того, что этот тип является ограниченным. А компилятор уже решает в какое машинное преобразование ему отобразить данное объявление типа. Но с другой стороны, мы говорим, что это совершено другой тип данных и никакого отношения к типу данных INTEGER он не имеет, т.е. это совсем не то, что означает запись на языке Паскаль “NATURAL = 0..MAXINT;” Такая запись говорит, что NATURAL – это диапазон и он такой же как INTEGER . Таким образом представление у них одинаковое. Здесь же ситуация выглядит совершенно иным образом: компилятор сам подбирает соответствующий набор машинных команд и форму трансляции для типа данных NATURAL. Данные типа NATURAL никак не могут быть связаны с типом данных INTEGER. Если мы преобразование.

Если программист хочет смешивать тип данных NATURAL и тип данных INTEGER, он может написать другое определение типа:

subtype NATURAL is INTEGER range 0..MAXINT;

Компилятор тут тоже сам решает как это наиболее эффективно запрограммировать, но отличие в том, что теперь переменные типа NATURAL и типа INTEGER можно смешивать. Программа пишется в терминах абстрактных типов данных, т.е. нет жесткой привязанности к архитектуре, и тем самым повышается ее мобильность.

В первых ЯП было еще и другое представление. В PLI и Коболе был тип DECIMAL (десятичный тип). Язык Кобол был разработан для коммерческих приложений, а они отличались от научно-технических тем, что в научно-технических вычислениях у нас есть, небольшое количество данных, обращенных, например, в матрицу размером 100х100, всего 10000 элементов, но над этим небольшим количеством данных выполняется большое количество операций. А в бизнес приложениях – очень большой набор данных, которые надо ввести и примитивный набор операций, который надо выполнить. Понятно, что основное время работы программы уходит на ввод и вывод, следовательно эффективность работы программы определяется, временем затрачиваемым на ввод и вывод данных и переводом из внешнего представления во внутреннее. На это обратили внимание разработчики машинных архитектур, начиная с IBM-360 стали появляться машинные типы данных, которые представляли из себя упакованные десятичные целые. По четыре бита у нас пакуется десятичная цифра. И есть специальные машинные команды, которые позволяют работать вот в таком упакованном десятичном формате. Операции выполняются медленно, расход памяти большой, но очень быстро происходи ввод и вывод, так как перевод из символьных форм и обратно тривиален. В архитектуре INTEL х86 есть отголоски этих упакованных десятичных целых. В С# есть тип данных desimal -- это

28-ми разрядные десятичные, операции над которыми выполняются точно.

Ни о какой фиксированной реализации этого типа данных говорить не приходится, здесь компилятор сам решает, как это запрограммировать. Этот тип данных появился из CLR (common language run-time), т.е. там есть все типы данных, которые присущи языкам “run-time”.

Вещественные числа имеют свое представление. Сейчас представление типа данных с плавающей точкой во всех архитектурах более-менее стандартизирована. Стандарт принят 90-х годах. В современных ЯП JAVA, C# есть тип данных float и double, первый соответствует 32-х битной реализации, а второй – 64-х битной. Представление их на любой архитектуре фиксировано.

Если взять вообще все архитектуры, то представление вещественных типов данных отличается, что влияет на переносимость программ. Язык Ада как ив случае с целыми типами данных задает так называемый «внутри компиляторный» подход. Программист работает в терминах абстрактной структуры типов данных, а компилятор уже решает как это преобразовать в машинное представление. Там появилось разделение вещественного типа данных на плавающий и фиксированный. Вещественный от целых типы данных с точки зрения машины отличаются тем, что операции на вещественными типами данных не точны, так как в ограниченном количестве битов нельзя представить все возможные вещественные числа. От сюда самая главная задача при работе с вещественными числами – это управление точностью. В Аде плавающий тип данных – это тип данных в котором зафиксирована точность, например,

type myreal is digits 10;

такое объявление говорит, что myreal -- это вещественный тип данных, для которого компилятор должен подобрать такое представление, чтобы в мантиссе были точно представлены 10 знаков. Т.е. для плавающих типов данных выбрана, так называемая, модельная реализация, вернее модельные числа, которые представлены в виде М*2^p, где 0.1<=M<1. Это нормализованное представление. Здесь мантисса выбирается таким образом, чтобы точно представлять 10 десятичных разрядов. Таким образом получается множество модельных чисел, а компилятор должен выбрать такую реализацию на целевой архитектуре, чтобы нужный тип входил как подмножество в множество чисел реализации. Программист следил за точностью, а компилятор за нужным представлением. Как показала практика такое представление оказалось несколько тяжеловато, поэтому в языка Ада было просто зафиксировано несколько базовых типов, которые предлагали использовать программистам.

Тем не менее в языке Ада появился тип данных с фиксированной точкой. Довольно часто вычисления, которые мы проводим имеют дело с вещественными числами, которые имеют ограниченную точность. Например датчик выдает значения от М до N с шагом h (меряем температуру от 0 до 100 градусов с точностью до 0.1 градуса), понятно, что какие бы вычисления не производились, точность все равно будет 0.1 градуса. Таким образом все данные датчика представлены в виде целого числа, а вот как интерпретировать это целое число с физической точки зрения – это уже другой вопрос. Вот для таких целей а языке Ада имеется фиксированный тип данных, т.е. внешне они выглядят как вещественные, но компилятор имеет право выбирать для них целочисленное представление. Это выглядит так:

Type Fixed is N..M delta h;

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

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