Б. Страуструп - Дизайн и Эволюция C++. 2006 (1160775), страница 64
Текст из файла (страница 64)
Если орегасог. () перегружен, то эквивалентность а ш и (йа) ->]и более не гарантируется. Но ее можно поддержать, нужным образом определив орегасог-> ( ) Это чересчур утомительно. Поэтому мы с Эндрю Кенигом и многие другие подумывали о том, чтобы применять орегасог. () к каждой операции над кейицп]. В этом случае наш пример работал бы правильно и при исходном определении Р.е ЙИцпс Однако если применять орегасог.
( ) таким образом, то для доступа к любому члену кейиц]п пришлось бы использовать указатель: ИИИИИШ1 Перегрузка 11.5.3. Перегрузка операторов инкремента и декремента Псрегружать операторы ннкремснта ++ и декремснта -- пользователи мотли всегда. Но в версии 1.0 не было механизма для различения прсфиксной н постфиксной нотации. Так, в классе с1аяя Рсх /! чо1«) орехасох»»(); )' один и тот жс Рсх:: орехасох++ ( ) использовался в следующих предложениях: »оха 1(Ряха р) ( р»»; ) !/р.орехохох++() //р.орехахох»»() Некоторые, в особенности Брайан Керннган, отмечали, что такое ограничение неестсственно для С и не дает программистам определить класс, который можно было использовать вместо обычного указателя.
Конечно, при проектировании механизма перегрузки операторов в С++ я думал о раздельной перегрузке прсфиксного и постфиксного инкрементов, но решил, что вводить для этой цели дополнительный синтаксис нс стоит. Многочисленныс предложения по этому поводу, полученные за несколько лет, доказали мою неправоту. Надо было лишь найти способ выразить различие между префнксной и цостфиксной нотацией с помощью минимальных изменений. Я разлумывал об очевидном решении — добавить в С++ ключсвые слова рхейкх и роясйкх: с1аяя Рхх Хо х гт и орехасоха ( ), так что я не считаю это серьезной проблемой. Однако сели поступить так, то получить доступ к членам класса, реализующего «умную» ссылку, нс удастся вообще. Например, пей))шп:: Ыпс) ( ) станет недоступной функпнсй.
Важно ли все вышесказанное? Некоторые отвечают: «Нет, поскольку «умную» ссылку, как и обычную, должно быть невозможно привязать к новому объекту», Однако мой опыт показывает, что для «умных» ссььчок операция повторной привязки или какая-то другая часто необходимы. Итак, мы оказались в затруднении; можно либо подлержать эквивалентность а. ю и (йа) ->ю, либо сохранить доступ к членам класса, реализующего «умную» ссылку, но не то и другое одновременно.
Одни из способов разрешить дилемму — использовать ореха сох. ( ) для а . и только в том случае, если класс ссылки сам не содержит члена с имснсм ~п. Мне такое решение нравится больше вссго. Однако по поводу важности перегрузки орехасох. ( ) нет единого мнения, она нс включена в С++, и ожссточенныс споры вокруг этого вопроса продолжаются. ":1ВИВИИИП Удобство нотации хь орегагог ргеНх++(); // префиксный ++ х орегагог рояг11х++(); // постфиксный ++ ИЛИ с1аяя Рог Го Х [ // хв ргег(х орегатог++(); // префиксный ++ х рояггтх орегагог++(); // постфиксный + ); но получил обычную порцию гневных отповсдей от людей, которым новые клю- чевые слова не по душе. Было предложено несколько вариантов без новых ключе- вых слов, например: с1аяя Рог Го Х ( // ХЬ ++орегасог(); // префиксный ++ Х орегасог++(); // постфиксный +я нлн с1аяя Рог Го Х ( // ха орегагог++(); // префиксный, поскольку возвращает ссылку Х орегагог++(); // постфиксный, поскольку не возвращает ссылку ): Первое решение показалось мне слишком заумным, второе — чересчур утонченным.
В конечном итоге я остановился на таком варианте: с1авя Ргг Го Х ( // ХЬ орегасог++(); Х орегасог++(гпс); // префиксный: нет аргументов // постфиксный, так как есть аргумент Это работает, не требует нового синтаксиса и имеет некоторую внутреннюю логику. Все остальные унарные операторы прсфиксные и не принимают аргументов, если определены как функции-члены. Достаточно необычный и посему неиспользуемый аргумент типа фпс употребляется для обозначения нс монсе необычного постфиксного оператора.
Другими словами, для постфиксных операторов е+ как бы стоит между первым (реальным) и вторым (воображаемым) операндом. Объяснения необходимы, так как описанный механизм нс имеет аналогов и потому выглядит чужеродным. Будь у меня выбор, я бы предпочел ключевые слова ргейфх и ронс11х, но в то время зто было невозможным. Имеет значение, однако, лишь то, что прием работает, а те немногие программисты, которым он действительно нужен, в состоянии его оценить и использовать. ИНИИИИИВ Перегрузка 11.5.5. Перегрузка оператора «запятая» По настоянию Маргарет Эллис я разрешил перегрузку оператора, (запятая). Главным образом потому, что не смог найти нричиц для отказа.
На самом деле причина есть: выражение а, Ь уже определено для любых а и Ь, поэтому перегрузка позволяет программисту изменить семантику встроенного оператора. Правда, это возможно лишь тогда, когда или а, или Ь являются объектами класса. На практике для использования орегагог, ( 1 причин мало, так что введен он, скорее, для поддержания единого стиля языка. 11.б.
Добавление в С++ операторов Сколько бы операторов ни было, их всегда не хватает. Создастся впечатление, что, если не считать тех программистов, кто в принципе против всяких операторов, все остальные постоянно мечтают о каких-нибудь дополнительных. 11 б.1. Оператор возведения в степень Почему в С++ нет оператора возведения в степень? Прежде всего потому, что его нет в С. Семантика операторов С выбрана максимально простой: все они соответствуют машинным командам обычного компьютера.
Оператор возведения в степень этому критерию не удовлетворяет. Оператор возведения в степень пе был добавлен в С++ сразу же. Моей целью было предоставление механизмов абстрагирования, а не новых примитивных операций. Оператору возведения в степень пришлось бы приписать семантику для встроенных арифметических типов. Но это та сторона С, которую я прсдпочел оставить без изменений. Далее, пользователи и так критиковали С и С++ за то, что в них слишком много операторов с неочевидными приоритетами.
Несмотря на эти сдерживающие факторы, я все-таки думал об операторе возведения в степень и, возможно, добавил бы его в язык, если бы не некоторые технические проблемы. Сомневаясь в реальной необходимости такого оператора в языке, поддерживающем перегрузку и встраивание вызовов функций, я все же считал лучшим включить его, просто чтобы опровергнуть общепринятое мнение о том, что без него никак не обойтись.
Пользователи хотели иметь оператор возведения в степень в виде **. Но это привело бы к осложнениям, поскольку выражение а**Ь допускается синтаксисом С и обозначает умножение на разыменованный указатель Ь. 11.5.4. Перегрузка ->в Перегружать оператор — >* было разрешено в основном потому, что для этого не было противопоказаний. Он оказался полезным для залания операций привязки, семантика которых по какой-то причине похожа на семантику встроенного оператора ->* (см.
раздел 13он). Никаких специальных правил не потребовалось; ->* велет себя, как любой бинарный оператор. Оператор . * не был включен в состав перегружасмых по той же причине, что и оператор . (см. раздел 11.5.2). Добавление в С++ операторов 1! ИИИИИИП оонЫе т(ооиЫе а, с)оише* Ы ( гестаса а**Ь; // означает а*(*Ы ) Кроме того, среди сторонников включения оператора возведения в степень не было согласия относительно его приоритета и ассоциативности: с = Ь**с**6; // (Ь**с)**о или Ь**(с**а)? а = -Ь**с; // (-Ы **с ини -(Ь**с)? В конце концов у меня не было большого желания описывать математические свойства операции возведения в степень.
В результате я решил, что для пользователей будет лучше, если я сосредоточусь на других вопросах. Оглядываясь назад, отмечу: все эти проблемы были разрешимы. Но нужно ли было решать их? Вопрос о нужности оператора встал ребром, когда в 1992 г. Мэтт Остерн (Магг Ацзгегп) представил комитету по стандартизации С++ законченное предложение.
Попутно оно обросло массой комментариев и стало предметом оживленной дискуссии в 1пгегпек Зачем пользователям нужен оператор возведения в степень: (з потому что они привыкли к нему в Рогггап; о пользователи полагают, будто оператор скорее окажется оптимизированным, чем функция возведения в степень; о вызов функции выглядит некрасиво в тех выражениях, которые обычно пишут физики и другие основные пользователи этого оператора.
Достаточно ли указанных причин, чтобы уравновесить технические сложности и возражения другой стороны? Можно ли преодолеть технические трудности? Рабочая группа по расширениям обсудила данные вопросы и решила не включать оператор возведения в степень. Итог подвел Дэг Брюк: о оператор дает некоторое удобство нотации, но не предоставляет никакой новой функциональности. Члены рабочей группы, представляющие интересы тех, кто постоянно выполняет научные или инженерные расчеты, отметили, что и удобство нотации минимально; о новое средство предстоит изучать каждому пользователю С++; о пользователи подчеркивали, что обязательно должна быть возможность подставить собственные функции возведения в степень вместо применяемых по умолчанию, а при наличии встроенного оператора это было бы невозможно; о предложение недостаточно мотивировано.
В частности, глядя на программу из 30 тыс. строк на Еогггап, нельзя было с уверенностью сказать, что этот оператор начнет широко использоваться в С++; о предложение требует добавления нового оператора и еще одного уровня приоритета, что усложнит язык. Приведенное краткое заключение далеко не полностью отражает глубину обсуждения вопроса. Так, некоторые члены комитета просмотрели множество написанных в разных компаниях программ и обнаружили, что возведение в степень не имеет такого принципиального значения, как подчас утверждается. Также было ИИИИИИИВ Перегрузка чоьб Г(бочЬ1е а, г)оиЬ1е Ь, гик* р) а**Ь; а**р; **а; **Р' // означает рон(а,ь) // означает а*(*р) // ошибка: а — не указатель // ошибка: означает *(*р), но *р — не указатель Разумеется, ** должна быть лексемой языка.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
