Б. Страуструп - Дизайн и Эволюция C++. 2006 (1160775), страница 37

Просмтор этого файла доступен только зарегистрированным пользователям. Но у нас супер быстрая регистрация: достаточно только электронной почты!

Текст из файла (страница 37)

Обзор возможностей Вот сводка возможностей С++, зафиксированных в ноябре 1994 г. в рабочих документах комитета на заседании, состоявшемся в Валли Фордж: сз возможности, описанные в АКМ (см. раздел 53); сз представление европейского набора символов (см. раздел 6.5.3.1); щ ослабление правила для типа возвращаемого значения в замещающих функциях (см. раздел 13.7); щ идентификация типов во время исполнения (см. раздел 14.2); а объявления в условиях (см. раздел 3.11.5.2); а перегрузка, основанная на перечислениях (см. раздел 11.7.1); й определенные пользователем операторы выделения и освобождения памяти для массивов (см. раздел 10.3); щ опережающие объявления вложенных классов (см.

раздел 13.5); а пространства имен (см. главу 17); а ключевое слово пшс аЬ1е (см. раздел 13.3.3); сз новый синтаксис приведения типов (см. раздел 14.3); а тип Ьоо1 (см. раздел 11.7.2); щ явное инстанцирование шаблонов (см. раздел 15.10.4); а явная спецификация аргументов в вызовах шаблонов функций (см. раздел 15.6.2); а шаблоны-члены (см. раздел 15.9.3); сз шаблоны классов как аргументы шаблонов (см. раздел 15.3.1); а возможность инициализировать константные статические члены интегральных типов константным выражением внутри объявления класса; а явные конструкторы (см. раздел 3.6.1); а статическая проверка спецификаций исключений (см.

раздел 16.9). Глава 6. Стандартизация Не пытайся перещеголять меня я эксцентричности. Зафод Библброкс 6.1. Что такое стандарт? В умах программистов царит путаница относительно того, что представляет собой стандарт и каким он должен быть. Вот один из идеалов: в стандарте полно и точно определяется, какие программы корректны н какова семантика каждой корректной программы.

В действительности такое определение не может и не должно быть идеалом для языков, которые спроектированы для работы с самыми разнообразными аппаратными архитектурами. Для подобных языков важно, чтобы определенные аспекты зависели от реализации. Таким образом, стандарт часто описывают как «контракт между программистом и разработчиком компилятора». Он определяет не только «корректный» исходный код, но и свойства, на которые программист может полагаться всегда, и зависящие от реализации. Например, в языках С и С++ разрешается объявлять переменные типа Бпс, но стандарт ничего не говорит о размере Бпс, кроме того что он не меньше 16 бит.

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

Многие члены комитета акцентируют свое внимание на технических вопросах языка, поэтому основные проблемы, связанные с тем, чту же именно стандартизируется, вынужден решать редактора комитета. К счастью, нашего первого редактора, Джонатана Шапиро, такие материи интересовали. Джонатан ушел с поста редактора, передав его Эндрю Кенигу. Но он и поныне остается членом комитета. Еще один интересный (то есть трудный) вопрос — до какой степени допустимы реализации, включающие возможности, не специфицированные в стандарте. В конце концов, некоторые расширения действительно необходимы тем или иным группам внутри сообщества пользователей С++.

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

Сформулировать стандарт так, чтобы расширения первого вида были возможны, а второго — нет, — нетривиальная задача. Также программа должна иметь возможность распознать нестандартные расширения. Иначе, проснувшись однажды утром, программист может обнаружить, что важнейший код зависит от расширения, предоставленного конкретным компилятором, а стало быть, сменить поставщика так просто уже не удастся. Я вспоминаю, как, будучи еще студентом, был приятно удивлен тем, что на нашем университетском компьютере установили «расширенный Еогггап» с некоторыми очень симпатичными возможностями. Но каково же было удивление, когда я понял, что все мои программы могут работать только на машинах серии СРС6000.

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

Кроме того, реальные программы обычно зависят от библиотек, предоставляющих сервисы, которые в некоторых системах просто отсутствуют. Например, программа, написанная под М1сгозоц '««1пг1овв, вряд ли будет без изменений работать под Х '»«чпг1отчз, а программу, в которой используются базовые классы Вог1апг1, не удастся без труда перенести на платформу МасАрр. Переносимость реальной программы определяется тем, насколько хорошо при ее проектировании были инкапсулированы зависимости от компилятора и окружения, а не только строгим соответствием немногим простым правилам, изложенным в стандарте. Б.1.1. Детали реализации Чуть ли не каждую неделю поступают просьбы стандартизировать такие аспекты, как расположение в памяти таблицы виртуальных функций, схему кодирования имен при типобезопасной компоновке или отладчик.

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

Такая универсальная стандартизация, наверное, даже и нежелательна; она затормозит прогресс в области машинных архитектур и операционных систем. Если пользователю нужна полная независимость от аппаратуры, систему следует НИИИИИИВ Стандартизация б.1.2. Тест на реалистичность Помимо многих формальных ограничений, которыми связан комитет по стандартизации, есть одно неформальное, но важное для практики.

На ряд стандартов потенциальные пользователи просто не обращают внимания. Например, практически забыты стандарты Рааса! и Рааса!2. Для большинства программистов на Рааса! само название языка означает расширенный диалект, введенный в обиход компанией Вог!апо. Язык, определенный стандартом Рааса!, не предоставлял средств, которые пользователи считали необходимыми, а Рааса!2 появился тогда, когда утвердился другой, неформальный «промышленный стандарты Еще одно настораживающее наблюдение: в среде ПХ1Х по-прежнему работают на Ке К С; АХБ1 С только борется за это сообщество. Некоторые пользователи не видят в АХБ1/1БО С таких технических преимушеств, которые оправдали бы краткосрочные неудобства при переходе. Даже к не вызывающему возражений стандарту приходится привыкать.

Для этого он должен быть принят вовремя и отвечать насущным потребностям. Попытка превратить С++ в «идеальный язык» или выпустить стандарт, не допускающий неверного истолкования никем, даже самым безграмотным человеком, — задача, непосильная ни для комитета (см. раздел 3.13), ни для иной организации, работающей на удовлетворение потребностей большого сообщества пользователей (см. раздел 7.1). 6.2. Работа комитета Для стандартизации С++ образовано несколько комитетов. Первый и самый крупный — комитет АХБ1-Х3116, сформированный Американским национальным институтом стандартизации (АХБ1). За этот комитет отвечает Ассоциация производителей компьютеров и оборудования для бизнеса (СВЕМА), поэтому он работает по установленным ею правилам.

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

Характеристики

Список файлов книги