Т. Пратт, М. Зелковиц - Языки программирования - разработка и реализация (4-е издание_ 2002) (1160801), страница 14
Текст из файла (страница 14)
Однако федеральные стандарты всегда принимаются в качестве общих, а о(1ЯТ, А)Ч51, 1ЕЕЕ и 1ЯО обычно разрабатывают стандарты совместно. Процесс разработки стандартов во всех подобных организациях одинаков. В некоторый момент специальная группа решает, что язык необходимо стандартиэовать. Затем совет по стандартам нанимает группу добровольцев для разработки стандарта.
Когда зта рабочая группа вырабатывает свой вариант стандарта, он переходит на голосование в группу заинтересованных лиц. Расхождения, выявленные при голосовании, прорабатываются, и затем выпускается стандарт языка. 1.3, Роль языков программирования 49 Хотя теоретически все выглядит хорошо, на самом деле создание стандартов является отчасти технической, а отчасти и политической проблемой.
Например, поставщики компиляторов имеют определенный финансовый интерес в созлании определенных стандартов. Естественно, они хотят, чтобы стандарт был как можно ближе к их компилятору, чтобы не пришлось вносить изменения в свою реализацию. Такие изменения не только дорого стоят сами по себе, они приводят еще и к тому, что программы пользователей, работающих с измененным компилятором, перестают отвечать станларту. Это, разумеется, созлает неудобства потребителям. Поэтому, как и отмечалось выше, создание стандартов — процесс, основанный на компромиссах. Не каждый извлекает из него выгоду, но все же имеется надежда что получивши йся в результате язык будет приемлемым для всех.
Рассмотрим следующий простой пример. В процессе обсуждения стандарта ГОКТКАЫ 77 все стороны пришли к соглашению, что поскольку большинство реализаций ЕОКТКАХ уже имели строки и подстроки, желательно стандартизовать такую возможность. Однако существовало несколько реализаций цодстрок. Для пояснения рассмотрим строку М = "аЬсЬе19". Согласно одной реализации, подстрока ьбсце" обозначалась М12: 5), то есть строка, состоящая из символов строки М со второго по пятый. В другой реализации та же подстрока обозначалась М12: 4), то есть строка, начинающаяся с позиции 2 и имеющая 4 символа. Если же считать символы справа налево, ту же подстроку можно было записать и как М13: б) .
Поскольку невозможно было достигнуть никакого соглашения по этому вопросу, было решено просто оставить его за рамками стандарта, Хотя этот стандарт не отвечает большинству высказанных вданной главе требований, принятое решение оказалось вполне подходящим. По этой причине стандарты являются полезными документами, но на определение языка могут оказать влияние некоторые сиюминутные политические соображения. Чтобы использовать стандарт эффективно, следует рассмотреть три аспекта стандартизации. 1. Своввречецность. Когда нужно стандартизовать язык? 2.
Соответстгае. Как определить, что программа соответствует стандарту, а компилятор компилирует согласно стандарту? 3. Уоларевание. Что обусловливает устаревание стандарта и как его следует модифицировать? Рассмотрим все эти вопросы по очереди. Своевременность. Одним из важных вопросов я вляется определение момента, хогди следует стандартизовать язык. Язык ЕОКТКАЫ впервые был стандартизован в 1966 г., когда уже существовало несколько несовместимых его версий. Это привело к некоторым проблемам, поскольку каждая реализация отличалась от других.
Другой крайностью является язык Аг)а, который впервые бьп стандартизован в 1983 г., еще до того, как возникла первая реализация. Когда создавался этот стандарт, еще никто не мог сказать, будет ли вообще этот язык работать. Первые эффективные компиляторы Ас!а появились только в 1987 г., а некоторые недостатки этого языка были обнаружены только при создании этих первых реализапий. Таким образом, слелует создавать стандарт языка не слишком рано, чтобы 50 Глава 1. Проблемы разработки языка накопилось достаточно опт па в его применении, но и не слишком поздно, чтобы не поощрять создание несовместимых реатизаций.
Из языков, описанных в данной книге, ЕОКТКАХ был стандартизован слишком поздно, когда было уже много несовместимых реализаций, а Ада, наоборот,— слишком рано, когда еще не было ни одной. Вовремя появились стандарты языков С н Рааса!, когда они уже начали распространяться, но еще не было большого количества несовместимых версий. Соответствие. Если существует стандарт языка, то, естественно, возникает вопрос о соответствии тому стандарту. Программа счикгается соответствующей стиндирту, если она использует только те возможности, которые определены данным стандартом. Компилятор является соответствующим стиндарту, когла после компиляции соответствующей стандарту программы прн ее выполнении получается правильный результат. Следует отметить, что здесь ничего не говорится о расширениях стандарта.
Если в компилятор добавлены дополнительные возможности, то любая программа, использующая эти возможности, нс является соответствующей стандарту и стандарт ничего не говорит о том, какими должны быть результаты выполнения таких программ. Стандарт обычно относится только к соответствующим стандарту программам. Вследствие этого большинство компиляторов всегда имеют возможности, которые не описаны стандартом. Поэтому следует проявлять осторожность прн использовании локальной реализации как окончательной инстанции при выяснении смысла какой-либо языковой конструкции. (В качестве примера можно рассмотреть программу аяоцз1у на языке Рааса!, приведенную в листинге 9.1.) Устаревание стандартов.
Накопленные знания н опыт программирования подсказывают, что развитие новых компьютерных архитектур требует включения в языки новых возможностей. Спустя несколько лет после утверждения стандарта языка, он может выглядеть весьма причудливо.
Так устарел исходный стандарт РОСТКАХ 66, поскольку в нем не предусмотрены многие возможности современных языков, такие как типы, вложенные управляю вгие структуры, инкапсуляция, блочная структура и многое другое из арсенала современных языков программирования. В связи с этим процесс стандартизации стал предусматривать возможность обновления. Каждый стандарт должен пересматриваться раз в пять лет и либо обновляться, либо совсем отменяться. Правда, всегда находится какая-либо причина для нарушения пятилетнего срока, но тем не менее такой процесс но большей части достаточно эффективен, Первый стандарт языка ГОКТКА11 был принят в 1966 г., затем он был пересмотрен в 1978 г. (хотя срок завершения разработки стандарта в 1977 г.
и был перенесен на несколько месяцев, язык все же называется ГОКТКАг1 77), а затем в 1990 г. стандарт был снова пересмотрен. Язык Ада бьп стандартизован в 1983 г., а пересмотрен в 1995 г. Один из вопросов, связанных с обновлением стандарта, заключается в следующем: что делать с уже существующим набором написанных в соответствии со старым стандартом программ? Компании затратили большие средства на создание программного обеспечения, а переписывать все сугцествующие программы под новую версию языка — весьма дорогостоящее мероприятие. Поэтому в болыиин- 1.3.
Роль языков программирования 51 стве стандартов требуется предусматривать обратную совместимость, то есть новый стандарт должен включать в себя более старые версии языка. Однако при этом возникают некоторые проблемы. Например, язык может стать слишком громоздким, если в неьч накапливать все устаревшие конструкции. Более того, некоторые из таких конструкций могут препятствовать разработке хорошей программы. Оператор Е001ЧАЕЕКСЕ языка РОЙТЕРА)ч' может служить примером такой устаревпшй конструкции.
Пусть Я вегцественное число, а 1 — целое, тогда последовательность операторов ЕСС1ЧАЕЕЯСЕ 1А. 11 Акдь1 1=1~1 располагает переменные й и 1 в одной и той же ячейке памяти. Первая процедура присваивания Ес переменной л) обращается к этой ячейке как к содержащей вещественное число и добавляет к нему единицу. Вторая процедура присваивания (с переменной 1) обращается к той жс ячейке как к содержащей уже целое число и также добавляет к нему единицу. Поскольку представления целых и вещественных чисел в большинстве компьютеров различны, то результат может быть совершенно непредсказуемым.
Поэтому сохранение этой конструкции языка нежелательно. В связи с вышесказанным нелавцо сформировались такие понятия, как устаревшая и не рекомендуемая возможности. Возможность называется устпреешей, если она является кандидатом на исключение из языка уже в следующей версии стандарта. Такое понятие предупреждает пользователей, что пока еще эта возможность доступна, но в ближайшие 5 — 10 лет она будет изъята нз стандарта языка. Таким образом, пользователи предупреждаются заблаговременно и имеют время переписать все коды, содержащие эту конструкцию. Пе рекожендуеиая возможность в очередном стандарте может стать устаревшей.
Таким образом, она может быть исключена из языка после двух его последу1огцих пересмотров. В этом случае предупредительный период составляет 10-20 лет. В новых программах такие возможности уже не следует использовать. Поскольку расширения языка допускаются и в согласующихся со стандартом компиляторах (до тех пор, пока опи правильно компилируют согласуюгциеся со стандартом программы), многие компиляторы пмшот дополнения, которые с точки зрения поставщика программного обеспечения являются полезными п способствуют распространению программного продукта.
Благодаря такому подходу появляются нововведения и развивается язык. Конечно, в академической среде большинство программистов не связывают себя никакими стандартами, а разрабатывают свои собственные продукты, в которых языки модифицированы и расширены подходяпгим для них образом. Это создает плодородную почву для испытания новых языковых концепций, а некоторые наиболее удачные идеи попадают в коммерческие языки и компиляторы. 1.3.4. Интернационализация В связи с глобализацией торговли и появлением Всемирной паутины Ч~ЪЧЪ' программирование становится все более и более глобальной деятельностью, и поэто- 52 Глава 1.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
