Х& operator prefix++() X operator postfix++()

префиксный ++ постфиксный ++

class Ptr to X { . . .

Х& prefix operator++() X postfix operator++()

префиксный ++ постфиксный

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

class Ptr to X { ...

Х& ++operator(: X operator++()

префиксный ++ постфиксный ++

class Ptr to X { . . .

Х& operator++О; префиксный, поскольку возвращает ссылку

X operator++(); постфиксный, поскольку не возвращает ссылку

Первое решение показалось .мне слишком заумным, второе - чересчур утои-ченны.м. В конечном итоге я остановился на таком варианте:

class Ptr to X { . . .

Х& operator++(); X operator++(int);

префиксный: нет аргументов

постфиксный, так как есть аргумент

Это работает, не требует нового синтаксиса и имеет некоторую внутреннюю логику. Все остальные унарные операторы префиксные и не принимают аргументов, если определены как функции-члены. Достаточно необычный и посему неиспользуемый аргумент типа int употребляется для обозначения не менее необычного постфиксного оператора. Другими словами, для постфиксных операторов ++ как бы стоит между первым (реальным) и вторы.м (воображаемым) операндом.

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

11.6. Добавление в С++ операторов

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

77.6.7. Оператор возведения в степень

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

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

Пользователи хотели и.меть оператор возведения в степень в виде **. Но это привело бы к осложнениям, поскольку выражение а**Ь допускается синтакси-со.м С и обозначает умножение па разыменованный указатель Ь.

11.5.4. Перегрузка ->*

Перегружать оператор ->* было разрешено в основном потому, что для этого не было противопоказаний. Он оказался полезным для задания операций привязки, семантика которых по какой-то причине похожа на семантику встроенного оператора ->* (см. раздел 13.11). Никаких специальных правил не потребовалось; ->* ведет себя, как любой бинарный оператор.

Оператор . * не был включен в состав перегружаемых по той же причине, что и оператор . (см. раздел 11.5.2).

77.5.5. Перегрузка оператора запятая

По настоянию Маргарет Эллис я разрешил перегрузку оператора , (запятая). Главным образом пото.му, что не смог найти причин для отказа. На самом деле причина есть: выражение а, b уже определено для любых а и Ь, поэто.му перегрузка позволяет програ.ммисту изменить семантику встроенного оператора. Правда, это возможно лишь тогда, когда или а, или Ь являются объектами класса. На практике для использования operator, () причин мало, так что введен он, скорее, для поддержания единого стиля языка.

double f(double а, double* b) {

return a**b; означает a*(*b)

Кроме того, среди сторонников включения оператора возведения в степень не было согласия относительно его приоритета и ассоциативности:

с = b**c**d; (b**c)**d или b**(c**d)? а = -b**c; (-b)**c или -(Ь**с)?

В конце концов у меня не было большого желания описывать математические свойства операции возведения в степень.

В результате я решил, что для пользователей будет лучше, если я сосредоточусь на других вопросах. Оглядываясь назад, отмечу: все эти проблемы были разрешимы. Но нужно ли было решать их? Вопрос о нужности оператора встал ребром, когда в 1992 г. Мэтт Остерн (Matt Austern) представил комитету по стандартизации С++ законченное предложение. Попутно оно обросло массой комментариев и стало пред.метом оживленной дискуссии в Internet.

Зачем пользователям нужен оператор возведения в степень:

□ потому что они привыкли к нему в Fortran;

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

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

Достаточно ли указанных причин, чтобы уравновесить технические сложности и возражения другой стороны? Можно ли преодолеть технические трудности? Рабочая группа по расширениям обсудила данные вопросы и решила не включать оператор возведения в степень. Итог подвел Дэг Брюк:

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

□ новое средство предстоит изучать каждому пользователю С++;

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

□ предложение недостаточно мотивировано. В частности, глядя на программу из 30 тыс. строк на Fortran, нельзя было с уверенностью сказать, что этот оператор начнет широко использоваться в С++;

□ предложение требует добавления нового оператора и еше одного уровня приоритета, что усложнит язык.

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