Лекции, страница 8

Типы диапазона.

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

Другой пример квазистатического контроля – это контроль над значениями диапазона. Рассмотрим пример на Паскале:

type T = A..B;

var i : T;

J : integer;

…

i := j; // компилятор вставит квазистатический контроль

j := i; // допустимое и безопасное присваивание

i := 2; // безопасность контролируется статически

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

Идеология языка Си абсолютно исключает всякий квазистатический контроль. Вы не найдете ни одной конструкции языка Си, которая бы использовала квазистатический контроль. И это понятно, потому что Си – это ассемблер по духу (только лучше, чем ассемблер), и поэтому, в свое время, все программисты быстро и охотно приняли язык Си. Например, в языке Си в принципе не возможно контролировать массивы, и это связано с арифметикой указателей. Выражение a+i (a – указатель, i – целое) может означать обращение к элементу массива a[i], а может и нет. В таких случаях, вся ответственность ложится на программиста, но зато программист знает, что его не обманывают, что лишнего кода никогда не будет.

Язык C++ разрабатывался в других условиях, но он полностью перенял идеологию языка Си, хотя C++ предлагает больше возможностей. Сохранилась старая концепция массивов, хотя Страуструп указывал, что массивы – одно из самых слабых мест языка Си. Аналогично с диапазонами – их нет, как и в Си, потому что диапазоны тоже требуют квазистатический контроль. Хотя Страуструп пытался сделать C++ как можно более надежным, он практически не расширил базис. Единственное расширение базиса – это понятие ссылки.

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

В языке Java понятие диапазона также отсутствует по вышеизложенным причинам, хотя квазистатического контроля там навалом (контролируется все что можно).

Символьный тип данных.

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

Почему в Си появился символьный тип данный? Не совсем только для вывода данных. На самом деле, символьная константа – это целое значение в Си. (Сразу проблема: 'A' – русская или английская буква? Какой у нее код?). Т.е. тип char – числовой тип данных. Этот тип появился как минимальный тип данных, потому что меньше символа адресовать не имеет смысла, и в то же время, символы тоже нужно адресовать.

Символьный тип данных, прежде всего, нужен для общения компьютера с человеком. Первая кодировка ASCII-7 была принципиально 7-битной и содержала символы от 0 до 127. И системы передачи данных тоже были 7-битными, и символьный тип данных был 7-битным, и операционные системы тоже были 7-битными. Естественно, были огромные трудности с локализацией программ. Даже когда появилась кодировка ASCII-8 (8-битная), кодовые страницы были заняты западными языками. Существует понятие ANSI_CHARSET, которое определяет отображение диапазона 0..255 на некоторый набор символов, включающих символы ASCII-7 и некоторых других алфавитов (кириллица туда не входит).

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

Что собой представляет символьный тип данных в языках программирования. В языке Ада символьный тип (CHARACTER) трактуется как перечислимый тип, т.е. 'A' – константа перечислимого типа, подобно тому, как в Си она принадлежит к числовому типу. Т.е. литеральной константе, в языке Ада, может соответствовать несколько перечислений. К сожалению, в стандарте зафиксировано, что литеры могут быть только из ASCII-7 (потом расширили до ANSI_CHARSET, но не более того). Все современные операционные системы, а они были написаны на языке Си (пример того, как язык влияет на мышление), в конечном итоге, определяли отображение некоторого 8-битного числа в какое-то изображение, определяемое шрифтом. Тут-то и началось… Рано или поздно кончилась холодная война, распался Варшавский договор, и стало нужно думать, например, о поляках. Тут то ANSI_CHARSET и сдох – в нем не было места для букв, соответственно, польского алфавита. Общий набор символов, которые употребляются в европейских языках, к сожалению, значительно больше, чем 256. А ведь есть еще Япония, Китай, Корея, Арабские страны, Израиль… Приходится думать и о других, и с этой точки зрения, разработка приложений неадекватна. В современных операционных системах появляются понятия, аналогичные code page в Windows. Code page определяет набор символов для данной страны.

Проблема в том, что нельзя все европейские языки уложить в набор из 256 символов. Более того, есть языки, один алфавит которых все равно не поместить в 256 символов. Появляются различные наборы символов (CHARSET): LATIN-1 (буквы европейских языков, которые в месте с ASCII-7, составляют ANSI_CHARSET), LATIN-2 (восточноевропейские языки, использующие латиницу), CYRILLIC и др. Code page – это попытка отобразить множество CHARSET. Например, code page 1252 соответствует LATIN-1, code page 1250 – это LATIN-2, code page 1251 – это русский CHARSET, code page 866 – русский CHARSET в DOS. В понятии шрифта также появляется понятие CHARSET, т.е. один и тот же шрифт (например, Times New Roman) может поддерживать различные CHARSET. Но если шрифт 8-битный, то он может поддерживать только один CHARSET из вышеперечисленных. Поэтому, если какой-то элемент управления работает только на одном шрифте и только на 8-битных символьных данных, то он не может отображать данные из различных CHARSET.

Впервые эта проблема была осознана в начале 80-х кодов, когда разбогатели японцы. Японцев после войны никто всерьез не воспринимал, а они работали, работали, и вдруг разбогатели. Оказалось, что им тоже нужны программные средства. Более того, они готовы были за них заплатить. Тут-то программисты прозрели. С этого момента множество трудов программистов было направлено на разработку приложений, которые можно было бы легко интернационализировать. Это очень нелегко. Между выходом американской и японской версией Windows 95 прошло полтора года. Примерно такая же ситуация и с приложениями.

Стало очевидным, что необходимо переходить от 8-битной кодировки к другой. Проснулся институт стандартизации (ISO) и решил, что если 8-ми битов не хватает, то 4-х байтов должно хватить (гулять так гулять). И был разработан стандарт UCS-4 (Universal Character Set). Сейчас человечество смогло пока заполнить только младшие два байта, которые стандартизованы под названием UCS-2, или UNICODE 2.0. UNICODE сконструирован достаточно умно. Большинство символьных данных по миру сейчас ходят в ASCII-7, поэтому получить символ ASCII-7 из UNICODE можно получить очень просто – для этого нужно взять 7 младших бит. России выделен диапазон 400-45F, причем в нем соблюдены традиционные соглашения об упорядочении русских букв, и по возможности, код плотный, т.е. за буквой А непосредственно следует Б.

В языке Java введен тип char, которому соответствует двухбайтный символ, и он предназначен для кодирования в стандарте UNICODE 2.0. Впервые наконец-то появился язык программирования, который пытается поддержать интернационализацию. Но сразу же появились и проблемы. UNICODE – это здорово, но представляете, что все символьные данные, которые написаны в языке Java, теперь будут ходить по Internet в два раза больше. Т.е. сети в два раза больше загружены. Тем более, что с корпоративной точки зрения, трафик идет 8-битный, а тут приходится еще таскать нулевой байт. Трафик возрастает в два раза. Сейчас скорость определяется уже не возможностями процессора и памяти, а возможностями средств коммуникации. И к этой проблеме нужно отнестись очень серьезно.

В связи с этой проблемой, появились форматы UTF (UCS Transformation Format). Есть формат UTF, который позволяет любой символ из UNICODE закодировать в виде последовательности 7-битных символов. Самым мощным форматом сейчас является формат UTF-8, который позволяет закодировать любой символ из UCS-4. Самый большой трафик идет в ASCII-7, поэтому все символы из ASCII-7 в UTF-8 выглядят точно также. А символы других CHARSET уже кодируются двумя байтами. Система кодировки очень проста: если старший бит содержит 0, то это байт ASCII. Если старший бит содержит 1, то далее число единичных битов означает число байт в коде, затем следует 0, и остающиеся биты служат для кодировки. Теперь все европейские алфавиты, кроме английского, кодируются двумя байтами, китайский алфавит кодируется тремя байтами. Таким образом, UTF за счет переменной длины кодировки, позволяет оптимизировать данные. Но про UTF-8 в стандарте Java ничего не говорится.

Хорошо, мы пишем на языке Java, символьный тип поддерживает UNICODE, в одной и той же строчке можно смешать тексты на совершенно разных языках. Можно ли написать на Java программу, в которой в одной строке будут разные языки? Ответ – нет! Потому что кроме языков программирования существуют еще, к сожалению, и операционные системы.

Лекция 8

С символьными типами данными связана только одна большая проблема - символьный тип совершенно неадекватен к некоторым применениям. То есть, например, писать программы в некоторой одноязычной среде достаточно просто, как только же нам приходится создавать многоязыковые программы, то тут проявляются сильные недостатки, как систем программирования, так и операционных систем. Дело в том, что исторически вопросы отображения символьных данных и их кода были отданы исключительно на откуп ОС. И, вообще говоря, это некоторый просчет создателей ЯП, просчет, за который сейчас расплачиваются программисты всего мира, да и не только они, но и промышленность. Одни - своими усилиями, другие - деньгами. И в последнее време наметились перспективы продвижения в этом отношении. Мы обсуждали стандарт UNICODE, коорый в свою очередь является частью еще более общего стандарта ISO-10646, который вводит некую универсальную систему кодирования. Из всех ЯП, которые мы рассматриваем, только Java поддерживает UNICODE прямо и непосредственно, то есть тип CHAR в этом языке - чисто unicode’овский тип данных. Заметим, что в C и C++ символьный тип данных является, прежде всего, целочисленным арифметическим типом данных. В Java нам всегда необходимо преобразование, но там тип CHAR c точки зрения множества значений эквивалентен типу SHORT, т.е. каждый unicode-символ представляется в ввиде знакового числа из двух байт.

Мы уже обсуждали некоторые проблемы, связанные с UNICODE, имеющие, прежде всего, социальные причины, так как большинство траффика по средствам коммуникации идет в семи- или восьми- битной кодировке. Семь бит - англоамериканский алфавит, восемь - другие языки (ANSI charset). Для решения этой проблемы были созданы некие трансформационные форматы (например UTF-8), которые мы обсуждали ранее.

Возникает вопрос. Например, Java поддерживает UNICODE, насколько просто создавать многоязыковые приложения на Java? К сожалению, нет. Почему? Это мы и попытаемся сейчас разобрать.

Строго говоря, тема создания многоязыковых приложений к теме ЯП не относится. Но виноваты в возникновении этой проблемы, как раз ЯП. В свое время было очень мало уделено значения представлению данных с точки зрения ЯП. Создателям ЯП казалось, что достаточно ввести понятие некоторого символьного типа данных, либо как числовое (C/C++), либо как отдельный тип (Pascal, Modula, Ada). Вопросы представления и кодировки совершенно не учитывались. Создатели были больше озабочены лексикой своих языков, то есть отображением данных на уровне стандартных устройств ввода-вывода, нежели на уровне программ. И это, вообще говоря, явилось недочетом.