□ нужно рассмотреть расширения, выходящие за пределы текущей практики применения С++;

□ должны быть рассмотрены библиотеки.

Ко всему прочему сообщество пользователей С++ было очень неоднородным и совершенно неорганизованным, поэтому комитету по стандартизации пришлось стать его центром. В краткосрочной перспективе именно это и было самой важной его целью:

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

Стандартизация - непростой процесс. В комитет входили люди, стремившиеся сохранить status quo; мечтавшие вернуться на несколько лет назад; были такие, кто хотел порвать с проклятым прошлым и спроектировать совершенно новый язык; те, кого волновал лишь один конкретный класс систем; люди, чьи голоса были куплены их работодателями, и представлявшие лишь самих себя; специалисты, озабоченные в основном теоретическими взглядами на программирование вообще и языки программирования в частности; нетерпеливые и требовавшие принять стандарт немедленно, даже если некоторые детали останутся неразрешенными, и наоборот, те, которых не устраивало ничего, кроме идеального определения языка. Были такие, кто полагал, что С++ - совсем новый язык, у которого и пользователей-то почти нет, и представители организаций, написавших за минувшее десятилетие миллионы строк кода, и т.д. Но в соответствии с правилами стандартизации нам всем предстояло прийти к более или менее одинаковому мнению. Мы должны были достичь консенсуса (обычно под этим словом понимают подавляющее большинство). Это разумные правила, они имеют национальный и интернациональный характер. Все интересы законны, и если позволить большинству ущемлять интересы меньшинст11; го получится стандарт, полезный лишь ограниченному кругу пользователей. Ili),)ioMy каждому члену комитета предстоит научиться уважать другие, чуждые ему точки зрения и идти на компромиссы. И это вполне соответствует стилю С++.

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

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

5,4.7. Обзор возможностей

Вот сводка воз.можностей С++, зафиксированных в ноябре 1994 г. в рабочих документах комитета на заседании, состоявшемся в Вэлли Фордж:

□ возможности, описанные в ARM (см. раздел 5.3);

□ представление европейского набора символов (см. раздел 6.5.3.1);

□ ослабление правила для типа возвращаемого значения в замещающих функциях (см. раздел 13.7);

□ идентификация типов во время исполнения (см. раздел 14.2);

□ объявления в условиях (см. раздел 3.11.5.2);

□ перегрузка, основанная на перечислениях (см. раздел 11.7.1);

□ определенные пользователем операторы выделения и освобождения памяти для массивов (см. раздел 10.3);

□ опережающие объявления вложенных классов (см. раздел 13.5);

□ пространства имен (см. главу 17);

□ ключевое слово mutable (см. раздел 13.3.3);

□ новый синтаксис приведения типов (см. раздел 14.3);

□ тип bool (см. раздел 11.7.2);

□ явное инстанцирование шаблонов (см. раздел 15.10.4);

□ явная спецификация аргументов в вызовах шаблонов функций (см. раздел 15.6.2);

□ шаблоны-члены (см. раздел 15.9.3);

□ шаблоны классов как аргументы шаблонов (см. раздел 15.3.1);

□ возможность инициализировать константные статические члены интегральных типов константным выражением внутри объявления класса;

□ явные конструкторы (см. раздел 3.6.1);

□ статическая проверка спецификаций исключений (см. раздел 16.9).

Глава 6. Стандартизация

Не пытайся перещеголять меня в эксцентричности.

Зафод Библброкс

6.1. Что такое стандарт?

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

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

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