сабж 

а функциями разве нельзя? или как надо? 

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

Добавлено @ 20:12 
Пыталась представить себе глобальную перегрузку оператора, скажем ()... 

Стандартный оператор () применим только к функциям. Значит, перегрузим мы его глобально, и вместо вызова ожидаемой функции с некоторыми типами аргументов будет вызываться... что? Другая функция? Очень полезно. Главное, наглядно.

Аналогично с другими операциями: [] в стандартном виде применим только к указателям-массивам и только с целыми индексами. Перегрузили. С индексами типа complex. А что, нельзя? Какой смысл будет иметь выражение pA[c], где pA указатель, а с - complex? Ммм... наверное индексация в двумерном массиве, не иначе...

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

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

Зачем запрещать, если можно разрешить. Неужели найдутся программисты, которые захотят использовать индексы типа complex? А дополнительные возможности (даже такие сомнительные) тоже могут кому-нибудь пригодиться IMHO. 

std::map. 

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

p.s приведи хоть один пример, где перегрузка глобальных [], (), -> может пригодится? 

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


До примеров я сейчас не додумаюсь. И прежде всего мне надо убедиться (а завтра убедить препода, который, возможно, задаст мне этот вопрос на зачете), что таких примеров нет.

PS Приведите, пожалуйста, пример, когда дружественной функцией перегружается оператор , (запятая). Вроде, ничуть не лучше, чем [ ]. Мне чего-то это начинает казаться бессмысленным.


Это другое дело 


А если левый операнд - член какого-нибудь библиотечного класса, к которому мы не можем добавить метод. Тогда, по аналогии с cin/cout мы можем только использовать дружественную функцию.

То есть нам, к примеру, нужно реализовать оператор вида a[ b ], где а - объект библиотечного класса, b - объект класса, который проетируем мы. Мы не можем добавить operator[] к методам библиотечного класса. Мы не имеем возможности реализовать такое методом нашего класса, поскольку ему через указатель this передается левый операнд. Остается только добавить к нашему классу дружественную функцию operator[] (const A & a, const B & b) или что-нибудь подобное.


А чем operator= лучше operator[] или ...-> или ...()? 
   

Это сообщение отредактировал(а) 0x07L - 15.6.2006, 22:24

я бы добавил ещё сравнение ==
Почему только это? А потому что копирование объектов ("=") может сопровождаться кучей условий и вызовом конструкторов, который не совершает "стандартная" операция копирования объектов. Почему сравнение? А чтоб упростить сравнение сложных типов - тех же списков или структур. 

Есть такое понятие - адаптер. Пиши свой класс, и делай с ним, что хочешь.

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


Как раз этот оператор можно переопределить глобально. Что, кстати, не очень здорово: можно запросто получить программу, где в одном месте объекты A сравниваются одним способом, а в другом - совершенно другим.

 

Earnest, знач, переопределять только в front-end модуле,  только в котором мы это сравнение и будем использовать и который не будет подключаться к другим модулям(в смысле, по задумке ЕГО не будут подключать) 

Это из серии "благими намерениями". 

Исходный код имеет тенденцию жить своей жизнью. Сначала ты переопределяешь глобальный оператор (скажем сравнения объектов A) в cpp-файле, и счастлив - быстро, удобно, работает. Потом постепенно разрастается  до неприличных размеров, и надо его делить. А как же наш специальный оператор? Он уже должен использоваться в 2 файлах. Дублируем код? Выносим в заголовок? И то, и другое одинаково плохо. 
Причем, заметь, это может сделать совсем другой программист (а не автор первой версии кода). Или автор, но через несколько лет.

Если какая-то гадость может случится, она рано или поздно обязательно случится. Причем тогда, когда об этой милой особенности уже никто не помнит.

А искать такие ошибки - сплошная радость. Гораздо проще написать класс - обертку, подогнав под свои нужды. Это уж точно никогда никому не повредит. 

OK
 

Earnest, полностью согласен. И рад, что в жизни не переопределял операторы, ибо с С++ почти не работаю    

2_MAKCim

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

2_Earnest

Дельное замечание.

---------------------------

Сегодня меня чуть не побили за то, что я задумал перегружать дружественными функциями операторы (), [], ->.
Приводили мне те же аргументы, что и Earnest в своем первом посте (левый операнд важнее правого).
Таким образом, это уже не личное мнение, а позиция большинства.
Так что от этих операндов я, пожалуй, отстану.

А вот относительно оператора присваивания меня переубедить не смогли.
Хотя...

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

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