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

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

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

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

void using{Table* namespace) { /* ... */ }

перестала компилироваться после введения пространств имен, поскольку using и namespace оказались ключевыми словами. Мой опыт, впрочем, показывает, что введение новых ключевых слов создает не.много пробле.м и все они легко решаются. С другой стороны, предложение ввести новое ключевое слово всегда вызывает взрыв негодования, хотя практические сложности можно свести к минимуму за счет выбора такого слова, которое вряд ли будет конфликтовать с именами идентификаторов. Именно по этой причине было выбрано using, а не use, и namespace, а не scope. Когда ради эксперимента мы без предварительного уведомления ввели ключевые слова using и namespace в используемый внутри фир.мы ко.мпилятор, никто за два месяца их даже не заметил.

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

6.4.4. Логическая непротиворечивость

На мой взгляд, основная трудность при рассмотрении расширения - обеспечить логическую непротиворечивость С++ и убедить пользователей в том, что

данная цель достигнута. Возможности, включаемые в С++, должны работать согласованно и компенсировать серьезные недостатки программы, синтаксически и семантически укладываться в структуру языка и способствовать разумному стилю програ.ммирования. Язык программирования не может быть просто собранием интересных возможностей, поэтому при оценке и включении расширений важно привести их к такому виду, чтобы они стали естественной частью языка. При серьезном анализе некоторых расширений, 95% времени уходит на то, чтобы найти фор.му оригинальной идеи, которая позволила бы гармонично интегрировать ее в С++. Обычно много сил тратится на выработку путей перехода к новой версии языка для разработчиков компиляторов и пользователей. Даже самое удачное средство приходится отклонять, если им нельзя будет воспользоваться, не удалив значительную часть прежнего кода и старых инструментальных средств.

6.5. Примеры предлагавшихся расширений

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

6.5.7. Именованные аргументы

Предложение Роланда Хартингера (Roland Hartinger) об именованных аргументах, т.е. о возможности при вызове функции задавать аргументы по имени, с технической точки зрения было близко к совершенству. Поэто.му особенно интересна причина, по которой его отклонили: группа по расширениям единодушно решила, что предложение не дает почти ничего нового, приведет к несов.местимости с существующи.м кодом и будет способствовать распространению неудачного стиля програ.ммирования. Ниже отражено обсуждение, состоявшееся по этому поводу в рабочей группе. Как обычно, сотни замечаний приходится опускать из-за недостатка места.

Рассмотри.м некрасивый, но, к сожалению, вполне реалистичный пример, заимствованный из аналитической статьи Брюса Эккеля (Bruce Eckel):

class window {

. . . public: window(

wintype=standard,

int ul corner x=0,

int ul corner y=0,

int xsize=100,

int ysize=100,

color Color=black,

border Border=single,

color Border color=blue,

WSTATE window staLe = operi) ; . . .

Если вы хотите 0111)сделить окно но умолчанию, все нормально. Определить же окно почти по умолчанию нелегко, при этом .можно наделать ошибок. Суть предложепня заключалась в том, чтобы ввести новый оператор : = н использовать его в вызовах фупкци11 для и.меиования аргумента. Напри.мер,

new v;ir;dow(Coior :=green,ysize:=150) ; будет эквивалентно предложению

new wi.ndow (standard, о , о , 100 ,150 ,green) ; что с учетом аргу.ментов по умолчанию эквивалентно

new windov;(standard, 0,0 , 100,150,green,single,blue,open);

Ha первый взгляд, это полезное синтаксическое удобство, которое .может сделать программы более надежны.ми. Предложение даже было реализовано, при этом НС возникло никаких концептуальных пробле.м. Кроме того, предложенный механизм основывался на опыте других языков, в частности, Ada.

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

□ удастся ли с по.мощью именованных аргументов писать более хороший код?

□ ие приведут ли эти аргументы к путанице или проблемам при обучении языку?

□ породят ли проблемы совместимости?

□ должны ли именованные аргументы стать одним из немногих расширений, которые мы одобрим?

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

□ аргументу необходимо иметь одно и то же имя в объявлении и определении функции;

□ если именованный аргумент использовался, то изменить его и.мя в определении функции уже нельзя, не нанеся ущерб пользовательской программе.

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