стороны, я как-то раз видел расширение , разрешаюшее доступ к закрытым членам класса из любой функции в программе, то есть разработчик не счел важной реализацию контроля доступа. Такую вольность я не считаю разумной. Сформулировать стандарт так, чтобы расширения первого вида были возможны, а второго - нет, - нетривиальная задача.

Также программа должна иметь возможность распознать нестандартные расширения. Иначе, проснувшись однажды утром, программист может обнаружить, что важнейший код зависит от расширения, предоставленного конкретным ко.мпилятором, а стало быть, сменить поставшика так просто уже не удастся. Я вспоминаю, как, будучи еще студентом, был приятно удивлен тем, что на наше.м университетском компьютере установили расширенный Fortran с некоторыми очень симпатичными воз.можностями. Но каково же было удивление, когда я понял, что все мои програ.ммы могут работать только на машинах серии CDC6000.

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

Кроме того, реальные программы обычно зависят от библиотек, предоставляющих сервисы, которые в некоторых системах просто отсутствуют. Например, профамма, написанная под Microsoft Windows, вряд ли будет без изменений работать под X Windows, а профамму, в которой используются базовые классы Borland, не удастся без труда перенести на платформу МасАрр. Переносимость реальной профаммы определяется тем, насколько хорошо при ее проектировании были инкапсулированы зависимости от компилятора и окружения, а не только строгим соответствием немногим простым правилам, изложенным в стандарте.

6.1.1. Детали реализации

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

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

строить как интерпретатор, предоставляющий приложениям собственную среду. Но у такого подхода есть свои нюансы: в частности, становится трудно воспользоваться особенностями специализированной аппаратуры и следовать локальным требованиям к стилю. Работая на языке, пригодном для построения серьезных систем, мы должны смириться с тем, что вновь и вновь наивный пользователь посылает в сетевую конференцию сообщение: Я перенес свой объект с Мае на SPARC, и он перестал работать . Как и переносимость, способность к взаимодействию - это вопрос проектирования и понимания тех ограничений, которые налагает среда. Некоторые программисты ие знают, что фрагменты, откомпилированные двумя разными компиляторами С для одной и той же системы, необязательно можно будет связать друг с другом (скорее всего, это не получится). И тем не менее они приходят в ужас, оттого что С++ не гарантирует такое взаимодействие. Это обычное явление, и мы должны просвещать пользователей.

6.1.2. Тест на реалистичность

Помимо многих формальных ограничений, которыми связан комитет по стандартизации, есть одно неформальное, но важное для практики. На ряд стандартов потенциальные пользователи просто не обращают внимания. Например, практически забыты стандарты Pascal и Pascal2. Для большинства программистов на Pascal само название языка означает расширенный диалект, введенный в обиход компанией Borland. Язык, определенный стандартом Pascal, не предоставлял средств, которые пользователи считали необходимыми, а Pascal2 появился тогда, когда утвердился другой, неформальный промышленный стандарт . Еще одно настораживающее наблюдение: в среде UNIX по-прежнему работают на K&R С; ANSI С только борется за это сообщество. Некоторые пользователи не видят в ANSI/ISO С таких технических преимуществ, которые оправдали бы краткосрочные неудобства при переходе. Даже к не вызывающему возражений стандарту приходится привыкать. Для этого он должен быть принят вовремя и отвечать насущным потребностям. Попытка превратить С++ в идеальный язык или выпустить стандарт, не допускающий неверного истолкования никем, даже самым безграмотным человеком, - задача, непосильная ни для комитета (см. раздел 3.13), ни для иной организации, работающей на удовлетворение потребностей большого сообщества пользователей (см. раздел 7.1).

6.2. Работа комитета

Для стандартизации С++ образовано несколько комитетов. Первый и самый крупный - ко.митет ANSI-X3J16, сформированный Американским национальным институтом стандартизации (ANSI). За этот комитет отвечает Ассоциация производителей компьютеров и оборудования для бизнеса (СВЕМА), поэтому он работает по уста1говленным ею правилам. В частности, это означает, что одна компания имеет один голос, а физическое лицо, не работающее ни в одной компании, рассматривается как компания. Член комитета может принимать участие в голосовании, начиная со второго заседания, на котором присутствует. Официально самым важным считается комитет WG-21, сформированный Международной

организацией по стандартизации (ISO). Он работает по международным правилам и принимает окончательное решение о придании стандарту статуса международного. В частности, действует правило одна страна - один голос . Другие страны, в том числе Великобритания, Гер.мания, Дания, Россия, Франция, Швеция и Япония, теперь и.меют собственные национальные комитеты по стандартизации С++, которые направляют запросы, рекомендации и своих представителей на совместные заседания комитетов ANSI/ISO.

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

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

ANSI и ISO проводят совместные заседания три раза в год. Чтобы не вносить путаницу, я буду называть две эти структуры словом комитет . Каждая встреча продолжается неделю, много часов уходит на решение процедурных вопросов. Но гораздо больше времени тратится на всякие недоразумения, неизбежные, когда 70 человек пытаются разобраться, чту же все-таки обсуждается. Несколько дневных и несколько вечерних заседаний носят технический характер: здесь обсуждаются такие вопросы, как международные наборы символов и идентификация типов во время выполнения, а также проблемы, относящиеся собственно к стандартизации, например формальные методики и организация международных структур по стандартизации. Остальное время отведено для встреч рабочих групп и обсуждений представленных ими отчетов.

Сейчас в работе участвуют такие группы:

□ по совместимости с С;

□ по ядру языка;

□ редакторская;

□ по окружению;

□ по расширениям;

□ по вопросам интернационализации;

□ по библиотекам;

□ по синтаксису.

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