Да вот же код класса с интами в качестве реальной и мнимой частей:


Если определено преобразование из double в complex (например, не explicit конструктор с один аргументом double), то в таком случае:

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

Реальное здесь переменные r и i, а мнимое, их инициализация  (:r(re),i(im) {}
)что ли?  Чет не вкурю логику  .


Определено программой или пользователем? Если пользователем, то как?


А я считал что будет работать из-за того что второй аргумент является типом[ B]complex[/B], Оператор ветдь принимает тип complex. Или я ошибаюсь  ???

Можно по подробнее описывать, а то я моло что понимаю  , все-таки начинающий.

 

программу пишет программист   
 

Если сложение реализовано как метод класса complex, то преобразовать a (которое у нас double)  в комплекс, а потом вызвать для него operator + компилятор не догадается. А для double оператора + (complex) нет.
То, как компилятор разрешает перегруженные имена, называется поиском Кенига. Во многих книгах по C++ это описано, почитай, весьма полезно. Вкратце, компилятор начинает с поиска подходящего метода класса. Если не нашел, ищет глобальный оператор в данной области действия (scope). И т.д. Важно то, что при поиске методов класса компилятор использует точный тип левого операнда. Т.е. методы класса complex вообще проверяться не будут, т.к. левый операнд у нас double.
 

Я полагаю поиск Кенига - это поиск имен в пространстве имен аргумента
Т. е если параметр принадлежит какому-то пространству имен и вызывается функция с этим параметром в качестве аргумента, то перегрузка идет с учетом поиска этой функции в этом пространстве имен 

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

 

Это сообщение отредактировал(а) UnrealMan - 17.6.2006, 18:01

Насколько строго должно выполняться требование константности? 

И все таки: Определение operator + () в классе предполагает (нужна для) обработку при соответствующих действиях (типа + (сложение) или / (деление)) над объектами соответствующего класса??? При чем вызываются эти операторы обычно  левым оператором (вернее operatorу() неявно передается ссылка на этот объект), при бинарной операции? Т.е. это как команда для компилятора, что нужно совершить те действия которые объявлены в теле operato+().   

Это сообщение отредактировал(а) AlanG - 17.6.2006, 13:44

Что ещё за левый оператор такой? :-) Наверно, ты имел в виду левый операнд, но тогда не понятно, как это операнд может вызывать оператор :-)

Для данного найденного в коде плюсика ищется соответствующий (наиболее подходящий – исходя из количества операндов, а также их типов) operator+. А вообще да будет Страуструп тебе в помощь. 

Это общепринятая идиома: оператор + не изменяет своих операндов - т.е. является константным, если определяется как метод.


Насколько я помню, это принцип поиска имен в С++ вообще, в том числе и то, что ты сказал.
 

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

Поиск Кенига понятие более конкретное в отличие от просто "поиск" 

Возвращаемое значение делают константным, чтобы ему нельзя было присваивать, т.е. компилятор ругался на конструкции типа a+b = f;
С моей точки зрения это из разряда "святее папы римского", т.е. не слишком обязательно. 

Ну это понятно.   


Уже помогает, купил >1000 страниц логического счястья  
 

UnrealMan, ставлю плюсик, но по моему не освещён вопрос о том, что плюс может быть в выражении с = (а+б+с)*в+..., то есть когда в формуле участвуют несколько операторов