Б. Страуструп - Дизайн и Эволюция C++. 2006 (1160775), страница 41
Текст из файла (страница 41)
Языковые средства хороши тем, что помогают программисту выразить свои идеи, уменьшают время отладки программы, делают код более понятным и облегчают его сопровождение. б.4.1 Критерии рассмотрения предложений Чтобы помочь пользователям понять, какие факторы должны сопутствовать внесению предложения о расширении или изменении С++, рабочая группа по расширениям сформулировала ряд вопросов, которые предположительно задаются соискателю [Бггопзсгцр, 1992Ь1: «Этот перечень содержит критерии оценки новых воэможностей С++: 0 точность формулировки. Ясно и точно опищите суть изменения и то, как оно отравится на текущем предварительном стандарте справочного руководства по языку: ПЕИИИИИИИ Стандартизация — какие потребуются изменения грамматики? — как изменится описание семантики языка? хорошо ли изменение согласуется с остальной частью языка? гз обоснование изменения: зачем нужно изменение? — для кого будетполезно? является ли оно изменением общего назначения? затрагивает ли предложение интересы одних групп пользователей С++ больше, чем других? — реализуемо ли оно на всех разумнмх аппаратных платформах и операционных системах? принесет ли ваше предложение пользу на всех разумных аппаратных платформах иоперационных системах? — какие стили программирования и проектирования поддерживает предполагаемое изменение? каким стилям программирования и проектирования оно мешает? — в каких язмках есть аналогичные средсша [если таковые существуют)? — упрощает ли оно проектирование, реализацию и использование библиотек? гз вероятность реализации.
Было ли реализовано ваше изменение? Если да, то в какой форме (я точности в той, какую вы предлагаете]? Если нет, почему вы думаете, что опыт аналогичных реализаций или других языков можно перенести на ту форму, в которой вы предлагаете свое средство? — как оно отразится на реализации С++? на организации компилятора? на поддержке времени исполнения? — была ли реализация полнойз — использовалась ли реализация кем-то, кроме разработчиков? ьз влияние изменения на код: как выглядит код без изменения? — что будет с кодом, если игнорировать внесение изменения? — предъявляет ли новое средство какие-то требования к инструментальным средствам? а влияние изменения на эффективность и совместимость с С и С++: как отразится ваше предложение на эффективности исполнения кода, в котором оно — используется? не используется? как изменение повлияет на время компиляции и компоновки? как оно отразится на существующих программах? нужно ли перекомпилировать код который не использует новое средство? повлияет ли изменение на возможность связывания с такими языками, как С или гогзгап? изменится ли качество статического или динамического контроля типов в программах иа С++? 'ьг простота документирования нового средство и легкость в обученииг — начинающих пользователей ? опытныхпользователвй? а причины, по которым не стоит принимать изменение.
Мы обязательно приведем контрдоводы, найти и оценить их — часть нашей работы. Поэтому вы можете сэкономить время, подготовившись к дискуссии по вопросам: отразится ли изменение на старом коде, который не использует новое средство? — трудно ли научить людей пользоваться им? Расширения $1ИВИИИЙ потребуются ли дальнейшие расширенияР увеличится п размер ко и л торов будет ли нужна обширная поддержка во время исполнения$ д существуют ли: альтернативные способы удовлетворить те жв лотребностиР иные варианты использования предложенного синтаксисов привлекательные обобщения предложенной схвмы1 Разумеется, список представленных вопросов — неполный. Пожалуйста, расширьте его, включив пункты, имеющие отношение к вашему предложению, и исключив те, которые к нему не относятся ж Эти вопросы всегда должны задавать себе проектирошцпки реальных языков.
бА.2. Текущее состояние дел Вот краткое оппсшшс ситуации после заседания комитета в Валли Фордж в ноябре 1994 г. Предлагать расширения лля Сев, похоже, стало популярным делом. Среди вариантов: ы расширенные (международныс) наборы символов (см, раздел 6.5.3.2); ы различные расширения шаблонов (см. разделы 15.3.1, 15 4, 15.8.2); ы сборка мусора (см.
раздел 10.7); ц предложения группы ХСЕО (например, см. раздел 6.5.2); ц объединения с дискриминантами; д опрслслснныс пользователем операторы (см. раздел 11.6.2); ц непрямые классы (1пп1гссч с1ачзсз); з перечисления с предопределенными операторами ++, «и т.лй :з перегрузка с учетом типа возвращаемого значения; ы составные операторы (см. раздел 11.6.3); л ключевое слово для нулевого указателя (Ицг.г., п(1 и т д ) — см. раздел 11.2 3; а пред- и постусловия; д улучшенные макросы для Срр; о повторная привязка ссылок; гд продолжения (сопйпггаГ!опз). Есть все же надежда па то, что атому потоку будет положен предел и что одобреннгяе расширения булут удачно интегрированы в язгвк.
До сих пор было принято лишь несколько новых возможностей, а именно: м обработка исключений — см.главу 16; ы шаблоны — см. главу 15; гд представление европейского набора символов (см, раздел 6.5.3.1); м ослабление правила для типа возврашаемого значения в замсшаюших функциях; ы идентификация типов во время исполнения (см, раздел 14.2); ш объявления в условиях (см, раздел 3.11.5.2); гд перегрузка, основанная на перечислениях (см. раздел 11.7.1); ы определенные пользователем операторы выделения и освобожлспия памяти лля массивов (см.
разлел 10.3); ПИИИИИИ11 Стандартизация гз опережающие объявления вложенных классов (см. раздел 13.5); л пространства имен (см. главу 17); а ключевое слово ппса)з1е (см. раздел 13.3.3); а тип Ьоо1еап (см. раздел 11.7.2); гз новый синтаксис приведения типов (см. раздел 14.3); гз оператор явного инстанцирования шаблона (см. раздел 15.10А); а явная спецификация аргументов в вызовах шаблонов функций (см. раздел 15.6.2); а шаблоны-члены (см.
раздел 15.9.3); о п~аблоны классов как аргументы шаблонов (см. раздел 15.3.1); гз возможность инициализировать константные статические члены интегральных типов константным выражением внутри объявления класса; ш явные конструкторы (см. раздел 3.6.1); ш статическая проверка спецификаций исключений (см. раздел 16.9). Исключения и шаблоны выделяются среди прочих расширений тем, что должны быть проработаны рабочей группой, входили в первоначальное предложение и описаны в АКМ. Кроме того, определить и реализовать их в два раза труднее, чем все остальные варианты. В то же время комитет отклонил много предложений, например: о несколько предложений о прямой поддержке параллельности; ы переименование унаследованных имен (см, раздел 12.8); а именованные аргументы (см. раздел 6.5.1); О несколько предложений по несущественным изменениям правил сокрытия данных; ы ограниченньш указатели (чродственник поа!)азь) — см.
раздел 6.5.2; ш оператор возведения в степень (см. раздел 11.5.2); ы автоматически генерируемые составные операторы; ы определяемые пользователем операторы и () (см. раздел 11.5.2); '.з вложенные функции; ш двоичные литералы; о обобщенная инициализация членов в обьявлении класса. Хочу подчеркнуть, что отклоненные возможности не обязательно плохи или бесполезны. На самом деле, ряд предложений, доходящих до комитета, исполнен технически грамотно и принес бы пользу, по крайней мере, некоторой части пользователей С++.
Просто большинство идей было недостаточно проанализировано и оформлено для того, чтобы называться предложениями. 6АЗ. проблемы, связанные с полезными расширениями Даже то расширение, которое нужно на самом деле, порожлает ряд проблем. Оно, как минимум, отвлекает силы разработчика от других важных задач. Например, что произойдет, если разработчику компилятора придется выбирать между реализацией нового средства и оптимизацией кодогенератора? Наверное, в большинстве случаев он отдаст предпочтение новому средству, поскольку оно более заметно для пользователей. ИИВИИИИПП Расширения Расширение может быть безупречным, если рассматривать его в отдельности от всего остального, и все же иметь недостатки, если видеть всю картину целиком.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
