лекции (1998) (Буров), страница 7

С этой точки зрения, эволюция языков программирования очень интересна. Рано или поздно, Дамоклов меч эффективности перестанет висеть над индустриальными языками программирования, и тогда программировать будет приятнее и легче, потому что куча проблем решится. Выделять память легко – сложнее ее освободить, и этим должна заниматься система. Но эффективный алгоритм динамического освобождения памяти возможен только в системах, типы которых строги. Они либо не содержат понятия указателя вообще, либо понятие указателя крайне ограничено (в стиле Ада-83 и Ада-95).

3.1.2. Другие базисные типы данных.

Оставшиеся типы данных можно классифицировать так:

1. Арифметические

1. целые

2. вещественные

1. Логические

2. Символьные

3. Перечислимые

4. Диапазоны

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

Программисты на языке Си понимают, что логический тип – это "ноль" и "не ноль". Программист на языке C++ знает, что есть тип данных bool, который по большому счету внес некоторую путаницу, поскольку в нем ноль означает ложь, а единица означает истину. Программист, который переключается с Си на C++, он встречает сообщения компилятора о потенциальной неэффективности. Например, некоторой переменной типа bool можно присвоить значение 18, и компилятор задействует преобразование типов, и переменная, в итоге, получит значение единицы. Причем, если логической переменной в C++ присвоить некоторое значение x, то компилятор вынужден будет вставить динамическое преобразование типа, которое связано с неэффективностью.

Аналогично, программист на Си скажет, что символьный тип – это целые числа. В каком диапазоне находятся эти числа? То ли в диапазоне –128..127, то ли в диапазоне 0..255. Это уже проблема: char – это знаковый или беззнаковый тип? В Паскале операция ORD(c) возвращала значение от –128 до 127. В языке Си такой определенности нет.

Перечисление – это отображение некоторого небольшого набора значений 0..N-1 в набор констант. Такого рода перечислимые типы позволяют сохранить содержательную роль объектов типа (обычно, это дни недели, цвета и т.д.). Понятно, что наличие разных перечислимых типов позволяет не складывать дни недели с цветами, цветы не перемножать на килограммы.

Целые типы данных.

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

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

Почему во многих языках программирования различаются знаковые и беззнаковые значения? Во первых, знаковая и беззнаковая арифметика, с точки зрения архитектуры компьютера, различаются. Операции над беззнаковыми числами выполняются чуть-чуть быстрее. И во вторых, изначально все системы реализовывались на 16-битных архитектурах, и в некоторых случаях диапазон –32768..32767 маловат, и хотелось бы увеличить диапазон до 0..65535 (особенно в тех случаях, когда число работает как счетчик или нужно для адресации). Т.е. беззнаковые типы возникли от бедности.

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

Когда Страуструп пытался улучшить язык Си, разрабатывая C++, он вполне всерьез, зная все эти проблемы, попытался запретить неконтролируемые преобразования знаковых в беззнаковые типы. Он думал, что переход на такую схему пройдет достаточно просто. Почему же Страуструп отступил от своего мнения? Он написал компилятор языка C++ на язык Си, и попытался узнать, а сколько программ использует такие неявные преобразования? И выяснил два факта. Все нетривиальные программы (в том числе профессиональные, зарекомендовавшие себя), написанные в языке Си, используют это неявное преобразование. Второй факт убил его больше. Оказалось, что программы самого Страуструпа, в том числе и программа компилятора, также используют неявное преобразование. Объяснил это Страуструп тем, что программисты понимают тонкие места в своих программах, и когда они употребляют эту конструкцию, они так или иначе уверены, что это будет безопасно. Поэтому Страуструп не ввел это ограничение. Тем не менее, проблема остается.

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

byte 8 бит

short 16 бит

int 32 бита

long 64 бита

Вещественные типы данных.

Для программистов на языке Си вещественные числа отождествляются с двумя типами данных – float и double (о соотношении этих типов известно только, что точность double ³ точности float). Такие типы данных называются плавающими. Они используют представление вида ±M*E^{^}exp, где M – мантисса, E – основание, exp – порядок. Основание обычно зашито в архитектуру машины, и хранить требуется только знак мантиссы, саму мантиссу, порядок (порядок – знаковый). Естественно, если люди не могут договориться о стандартизации представления целых чисел, то тем более они не могут договориться о стандартизации вещественных чисел. Постулируется только то, что вычисления с числами этих типов не точны, причем точность не известна. К счастью, ситуация меняется от плохого к лучшему. В настоящее время существует стандарт описания вещественной арифметики IEEE 754, и именно этот стандарт используется в языке Java.

Поскольку основная цель Java – переносимость, то в этом языке стандартизована длина и семантика вещественных типов:

float 4 байта

double 8 байт

Кроме того, в Java появилась константа NaN (Not a Number), которая является результатом ошибок, типа деления на ноль. Это число не равно никакому другому вещественному числу, в том числе, и самому себе.

Но это подход середины 90-х годов, поскольку именно к этому времени оформился этот стандарт. Интересен подход более старого (чем Java) языка Ада, который с точки зрения математических вычислений, является лучшим языком, из тех, которые мы рассматриваем.

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

type MY_REAL is digits 8;

Вычисления с плавающей точкой не точны, и мы можем говорить только о точности мантиссы (из-за разного порядка, о точности вообще говорить нельзя). При определении вещественного типа данных, определяется точность мантиссы в десятичных знаках, а компилятор уже должен подбирать соответствующее представление таким образом, чтобы обеспечить эту точность. Каков же будет диапазон вещественных чисел? Пусть B – число битов в мантиссе, тогда B = [ D * lg10/lg2 + 1 ], где D – точность мантиссы в десятичных знаках. Порядок в этом случае меняется в диапазоне 4^-B £ Eexp £ 4B.

В чем возникла проблема? Написать то можно все, но как на конкретных архитектурах подобрать нужное представление? Можно задать большое число знаков, и тогда необходима библиотека, которая эмулирует математические вычисления, если не хватает возможностей аппаратуры. Эту проблему создатели Ады так до конца и не преодолели, но они не виноваты, потому что, либо надо было поступаться точностью, либо эффективностью. На уровне языка компромисс разрешить нельзя.

Требование Ады заключается в том, что допустимы только такие объявления вещественных типов, которые "влезают" в данную реализацию. Если не "влезают", то реализация вправе отказать в объявлении такого типа. Эта проблема решиться только тогда, когда производители оборудования примут стандарт, и этот стандарт будет встроен в языки программирования.

Однако язык Ада пошел дальше. Было введено понятие чисел с фиксированной точкой.

Довольно часто в математических вычислениях возникает ситуация, когда есть отрезок от A до B (по которому, например, нужно вычислить интеграл), есть некоторое число разбиений этого отрезка N, каждое из которых по длине равно H=(A+B)/N. Число H, конечно же, представляется как вещественное число. Здесь возникает погрешность вычислений чисел с плавающими точками. Понятно, что в зависимости от величины числа N и от длины отрезка AB, требуются разные точности. В такой задаче не всегда удобно использовать числа с плавающей точкой.

В языке Ада появились фиксированные типы – это вещественные типы, которые представляются с помощью целых чисел. При использовании этих типов в такого рода задачах, точность вычислений выше. Кроме того, число с фиксированной точкой хранится проще. Фиксированные типы должны описываться в терминах диапазона, а также в терминах некоторой точности.

type T is delta d of range L..R

type Mesh is delta 0.01 of range A..B;

Перечислимые типы данных.

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

Перечисление в языке Си – это удобный способ задания целочисленных констант. Между описанием enum имя {A,B,C} и описанием const int A=0; const int B=1; const int C=2; никакой разницы нет.

В таких языках как Паскаль, Модула-2, Ада – подход более жесткий. Перечислимые типы данных никак не совместимы с целыми типами данных, хотя есть операция VAL(T,E), возвращающая целое значение константы E, принадлежащей типу T. Есть также операция T(i), которая возвращает имя константы типа T, с номером i. Т.е. есть операции перевода из перечислимого типа и обратно, и эти операции безопасны. Хотя может возникнуть проблема, если i выйдет за пределы диапазона перечислимого типа. Поэтому в этих случаях, компилятор вставляет динамические проверки.

В языке C++, из соображений совместимости, требовалось принять "плохой" подход языка Си, в котором значения перечислимого типа отождествляются с константами, и никаких проверок нет. Такой подход выхолащивает значительную долю привлекательности перечислимых типов, и Страуструп это понимал. Кроме того, уж если мы вводим новый тип данных, то хотелось бы, чтоб это действительно тип данных, т.е. например, чтобы он отличался от целых типов данных с точки зрения перекрытия операций (когда для разных типов имя операции одно и тоже, но тело разное, и компилятор делает выбор в процессе компиляции в зависимости от типов операндов). Страуструп вывернулся из этой ситуации путем сложных формулировок понятия перекрытия, и правила выбора корректного тела в C++ очень сложны. Кроме того, присваивание T=i запрещено, а присваивание i=T разрешено.

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

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