- какие потребуются изменения грамматики?

- как изменится описание семантики языка?

- хорошо ли изменение согласуется с остальной частью языка?

□ обоснование изменения:

- зачем нужно изменение?

- для кого будет полезно?

- является ли оно изменением общего назначения?

- затрагивает ли предложение интересы одних групп пользователей С++ больше, чем других?

- реализуемо ли оно на всех разумных аппаратных платформах и операционных системах?

- принесет ли ваше предложение пользу на всех разумных аппаратных платформах и операционных системах?

- какие стили программирования и проектирования поддерживает предполагаемое изменение?

- каким стилям программирования и проектирования оно мешает?

- в каких языках есть аналогичные средства (если таковые существуют)?

- упрощает ли оно проектирование, реализацию и использование библиотек?

□ вероятность реализации. Было ли реализовано ваше изменение? Если да, то в какой форме (в точности в той, какую вы предлагаете)? Если нет, почему вы думаете, что опыт аналогичных реализаций или других языков можно перенести на ту форму, в которой вы предлагаете свое средство?

- как оно отразится на реализации С++?

- на организации компилятора?

- на поддержке времени исполнения?

- была ли реализация полной?

- использовалась ли реализация кем-то, кроме разработчиков?

□ влияние изменения на код:

- как выглядит код без изменения?

- что будет с кодом, если игнорировать внесение изменения?

- предъявляет ли новое средство какие-то требования к инструментальным средствам?

□ влияние изменения на эффективность и совместимость с С и С++:

- как отразится ваше предложение на эффективности исполнения кода, в котором оно

- используется?

- не используется?

- как изменение повлияет на время компиляции и компоновки?

- как оно отразится на существующих программах?

- нужно ли перекомпилировать коя который не использует новое средство?

- повлияет ли изменение на возможность связывания с такими языками, как С или Fortran?

- изменится ли качество статического или динамического контроля типов в программах на С++?

□ простота документирования нового средства и легкость в обучении:

- начинающих пользователей?

- опытных пользователей?

□ причины, по которым не стоит принимать изменение. Мы обязательно приведем контрдоводы, найти и оценить их - часть нашей работы. Поэтому вы можете сэкономить время, подготовившись к дискуссии по вопросам:

- отразится ли изменение на старом коде, который не использует новое средство?

- трудно ли научить людей пользоваться им?

- потребуются ли дальнейшие расширения?

- увеличится ли размер компилятора?

- будет ли нужна обширная поддержка во время исполнения?

□ существуют ли:

- альтернативные способы удовлетворить те же потребности?

- иные ворианты использовония предложенного синтаксиса?

- привлекотельные обобщения предложенной схемы?

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

Эти вопросы всегда должны задавать себе проектировщики реальных языков.

6.4.2. Текущее состояние дел

Вот краткое oinicanne ситуации после заседания ко.митета в Вэлли Фордж в ноябре 1994 г. Предлагать растирения для С ++, похоже, стало популярлы.м делом. Среди вариантов:

J расширенные (международные) наборы символов (см. раздел 6.5.3.2); J различные расширения шаблонов (см. разделы 15.3.1, 15.4, 15.8.2);

□ сборка .мусора (см. раздел 10.7);

□ предложения группы NCEG (например, см. ра;здел 6.5.2);

□ объединения с дискриминантами;

J определенные пользователем операторы (см. раздел 11.6.2);

□ непрямые классы (indirect cla.sses);

□ перечисления с предопределенными операторами ++, << и т.д.;

□ перегрузка с учетом типа возвращаемого значения;

□ составные операторы (см. раздел 11.6.3);

□ ключевое словодля нулевого ука.зателя (NULL, nil и т.д.) - см. ра.здсл 11.2.3;

□ пред-и постусловия;

□ улучшенные макросы для Срр;

□ повторная привязка ссылок;

□ продолжения (continuations).

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

□ обработка исключешгй - см. главу 16;

□ шаблоны - см. г;1аву 15;

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Исключения и шаблоны выделяются среди прочих расширений тем, что должны быть проработаны рабочей группой, входили в первоначальное предложение и описаны в ARM. Кро.ме того, определить и реализовать их в два раза труднее, чем все остальные варианты.

В то же вре.мя комитет отклонил много предложений, например:

□ несколько предложений о прямой поддержке пара.тлельности;

□ переименование унаследованных и.мен (см. раздел 12.8);

□ именованные аргументы (см. раздел 6.5.1);

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

□ ограниченные указатели ( родственник noalias ) - см. раздел 6.5.2;

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

□ автоматически генерируемые составные операторы;

□ определяемые пользователем операторы и {) (см. раздел 11.5.2);

□ вложенные функции;

□ двоичные литералы;

□ обобщенная инициализация членов в объявлении класса.

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

6.4.3. Проблемы, связанные с полезными расширениями

Даже то расширение, которое нужно на са.мом деле, порождает ряд проблем. Оно, как минимум, отвлекает силы разработчика от других важных .задач. Например, что произойдет, если разработчику ко.мпилятора придется выбирать между реализацией нового средства и оптимизацией кодогенератора? Наверное, в большинстве случаев он отдаст предпочтение новому средству, поскольку оно более заметно для пользователей.