поскольку 4auie всего его невозможно реализовать, не вводя флаги, гарантирующие, что временный объект уничтожается, только когда он появился именно в той ветви, по которой пошло выполнение. Однако разработчики компиляторов ответили на вызов и продемонстрировали, что возникающие затраты чрезвычайно малы.

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

Разрешив уничтожать временные объекты в конце полного выражения, .мы разрушили некоторые программы, компилировавшиеся ранее Cfront, но все гарантии, предоставленные ARM, были сохранены. Принятое решение отражает желание иметь четко определенное и легко поддающееся объяснению местоположение точки уничтожения. Оно также согласуется с желанием не хранить временные объекты слишком долго. Объекты, которые должны существовать дольше, надо именовать, или использовать приемы, не требующие долгоживущих временных объектов. Например:

void f(String si. String s2) {

printf( %s , sl+s2); правильно const char* p = sl+s2;

printf( %s , p); не работает, временный объект уничтожен String s3 = sl+s2;

printf ( %s, (const char*)s3); правильно cout s3; правильно cout sl+s2; правильно

>

6.4. Расширения

Исключительно важным был и остается вопрос о том, как справиться с нескончаемым потоком предложений об изменениях и расширениях языка. Основная роль при его решении отводится рабочей группе по расширениям, в которой я являюсь председателем. Любое предложение гораздо проще принять, че.м отвергнуть. Так вы приобретаете друзей, а люди ценят язык, в котором много полезных штучек . Однако язык, построенный как конгломерат средств, внутренне не связанных между собой, неудачен, поэтому нет никакой возможности принять даже большую часть средств, которые были бы по-настоящему полезны той или иной части сообщества пользователей C-t-ь.

На вышеупомянутой встрече в Лунде была очень популярна такая история [Stroustrup,1992b]:

Мы часто вспоминаем о прекрасном корабле Vasa . Он был гордостью шведского Военно-морского флота, самым большим и красивым из когда-либо построенных военных судов. К сожалению, во время строительства в проект были внесены существенные изменения, поскольку

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

Зачем вообще рассматривать расширения? Ведь X3J16 - это комитет по стандартизации, а не группа проектирования, которая обязана разработать язык C-i~i-i-i- . Да и не может коллектив из 250 человек с переменным составом надеяться на успех в области проектирования языка.

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

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

Итак, у комитета был выбор: обсуждать расширения, рассматривать диалекты уже после их появления или игнорировать ситуацию. Подобие дилеммы вставали перед разными комитетами по стандартизации, и каждый принимал свое решение. Большинство, в том числе комитеты по языкам Ada, С, Cobol, Fortran, Modula-2 и Pascal-2, решали вопрос в пользу рассмотрения расширений.

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

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

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

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

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

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

6.4.1. Критерии рассмотрения предложений

Чтобы помочь пользователям понять, какие факторы должны сопутствовать внесению предложения о расширении или изменении С++, рабочая группа по расширениям сформулировала ряд вопросов, которые предположительно задаются соискателю [Stroustrup, 1992b]:

Этот перечень содержит критерии оценки новых возможностей С++:

□ точность формулировки. Ясно и точно опишите суть изменения и то, как оно отразится на текущем предварительном стандарте справочного руководства по языку: