Операторная функция должна быть либо членом, либо иметь по крайней мере один параметр, являющийся объектом класса (для функций, переопределяющих операции new и delete, это не обязательно). Это правило гарантирует, что пользователь не сумеет изменить интерпретацию выражений, не содержащих объектов пользовательского типа. В частности, нельзя определить операторную функцию, работающую только с указателями. Этим гарантируется, что в С++ возможны расширения, но не мутации (не считая операций =, &, и, для объектов класса). Операторная функция, имеющая первым параметр основного типа, не может быть функцией-членом. Так, если мы прибавляем комплексную переменную aa к целому 2, то при подходящем описании функции-члена aa+2 можно интерпретировать как aa.operator+(2), но 2+aa так интерпретировать нельзя, поскольку не существует класса int, для которого + определяется как 2.operator+(aa). Даже если бы это было возможно, для интерпретации aa+2 и 2+aa пришлось иметь дело с двумя разными функциями-членами. Этот пример тривиально записывается с помощью функций, не являющихся членами. Каждое выражение проверяется для выявления неоднозначностей. Если пользовательские операции задают возможную интерпретацию выражения, оно проверяется в соответствии с правилами $$R.13.2.
Пользовательские операции преобразования типа
Описанная во введении реализация комплексного числа является слишком ограниченной, чтобы удовлетворить кого-нибудь, и ее надо расширить. Делается простым повторением описаний того же вида, что уже были применены: class complex { double re, im; public: complex(double r, double i) { re=r; im=i; } friend complex operator+(complex, complex); friend complex operator+(complex, double); friend complex operator+(double, complex); friend complex operator-(complex, double); friend complex operator-(complex, double); friend complex operator-(double, complex); complex operator-(); // унарный - friend complex operator*(complex, complex); friend complex operator*(complex, double); friend complex operator*(double, complex); //... }; Имея такое определение комплексного числа, можно писать: void f() { complex a(1,1), b(2,2), c(3,3), d(4,4), e(5,5); a = -b-c; b = c*2.0*c; c = (d+e)*a; } Все-таки утомительно, как мы это только что делали для operator*() писать для каждой комбинации complex и double свою функцию. Более того, разумные средства для комплексной арифметики должны предоставлять десятки таких функций (посмотрите, например, как описан тип complex в <complex.h>).
Конструкторы
Вместо того, чтобы описывать несколько функций, можно описать конструктор, который из параметра double создает complex: class complex { //... complex(double r) { re=r; im=0; } }; Этим определяется как получить complex, если задан double. Это традиционный способ расширения вещественной прямой до комплексной плоскости. Конструктор с единственным параметром не обязательно вызывать явно: complex z1 = complex(23); complex z2 = 23; Обе переменные z1 и z2 будут инициализироваться вызовом complex(23). Конструктор является алгоритмом создания значения заданного типа. Если требуется значение некоторого типа и существует строящий его конструктор, параметром которого является это значение, то тогда этот конструктор и будет использоваться. Так, класс complex можно было описать следующим образом: class complex { double re, im; public: complex(double r, double i =0) { re=r; im=i; } friend complex operator+(complex, complex); friend complex operator*(complex, complex); complex operator+=(complex); complex operator*=(complex); //... }; Все операции над комплексными переменными и целыми константами с учетом этого описания становятся законными. Целая константа будет интерпретироваться как комплексное число с мнимой частью, равной нулю. Так, a=b*2 означает a = operator*(b, complex(double(2), double(0))) Новые версии операций таких, как +, имеет смысл определять только, если практика покажет, что повышение эффективности за счет отказа от преобразований типа стоит того. Например, если выяснится, что операция умножения комплексной переменной на вещественную константу является критичной, то к множеству операций можно добавить operator*=(double): class complex { double re, im; public: complex(double r, double i =0) { re=r; im=i; } friend complex operator+(complex, complex); friend complex operator*(complex, complex); complex& operator+=(complex); complex& operator*=(complex); complex& operator*=(double); //... }; Операции присваивания типа *= и += могут быть очень полезными для работы с пользовательскими типами, поскольку обычно запись с ними короче, чем с их обычными "двойниками" * и +, а кроме того они могут повысить скорость выполнения программы за счет исключения временных переменных: inline complex& complex::operator+=(complex a) { re += a.re; im += a.im; return *this; } При использовании этой функции не требуется временной переменной для хранения результата, и она достаточно проста, чтобы транслятор мог "идеально" произвести подстановку тела. Такие простые операции как сложение комплексных тоже легко задать непосредственно: inline complex operator+(complex a, complex b) { return complex(a.re+b.re, a.im+b.im); } Здесь в операторе return используется конструктор, что дает транслятору ценную подсказку на предмет оптимизации. Но для более сложных типов и операций, например таких, как умножение матриц, результат нельзя задать как одно выражение, тогда операции * и + проще реализовать с помощью *= и +=, и они будут легче поддаваться оптимизации: matrix& matrix::operator*=(const matrix& a) { //... return *this; } matrix operator*(const matrix& a, const matrix& b) { matrix prod = a; prod *= b; return prod; } Отметим, что в определенной подобным образом операции не нужных никаких особых прав доступа к классу, к которому она применяется, т.е. эта операция не должна быть другом или членом этого класса. Пользовательское преобразование типа применяется только в том случае, если оно единственное($$7.3.3). Построенный в результате явного или неявного вызова конструктора, объект является автоматическим, и уничтожается при первой возможности,- как правило сразу после выполнения оператора, в котором он был создан.
Операции преобразования
Конструктор удобно использовать для преобразования типа, но возможны нежелательные последствия: [1] Неявные преобразования от пользовательского типа к основному невозможны (поскольку основные типы не являются классами). [2] Нельзя задать преобразование из нового типа в старый, не изменяя описания старого типа. [3] Нельзя определить конструктор с одним параметром, не определив тем самым и преобразование типа. Последнее не является большой проблемой, а первые две можно преодолеть, если определить операторную функцию преобразования для исходного типа. Функция-член X::operator T(), где T - имя типа, определяет преобразование типа X в T. Например, можно определить тип tiny (крошечный), значения которого находятся в диапазоне 0..63, и этот тип может в арифметических операциях практически свободно смешиваться с целыми: class tiny { char v; void assign(int i) { if (i>63) { error("выход из диапазона"); v=i&~63; } v=i; } public: tiny(int i) { assign(i) } tiny(const tiny& t) { v = t.v; } tiny& operator=(const tiny& t) { v = t.v; return *this; } tiny& operator=(int i) { assign(i); return *this; } operator int() { return v; } }; Попадание в диапазон проверяется как при инициализации объекта tiny, так и в присваивании ему int. Один объект tiny можно присвоить другому без контроля диапазона. Для выполнения обычных операций с целыми для переменных типа tiny определяется функция tiny::operator int(), производящая неявное преобразование типа из tiny в int. Там, где требуется int, а задана переменная типа tiny, используется преобразованное к int значение: void main() { tiny c1 = 2; tiny c2 = 62; tiny c3 = c2 -c1; // c3 = 60 tiny c4 = c3; // контроля диапазона нет (он не нужен) int i = c1 + c2; // i = 64 c1 = c2 + 2 * c1; // выход из диапазона: c1 = 0 (а не 66) c2 = c1 - i; // выход из диапазона: c2 = 0 c3 = c2; // контроля диапазона нет (он не нужен) } Более полезным может оказаться вектор из объектов tiny, поскольку он позволяет экономить память. Чтобы такой тип было удобно использовать, можно воспользоваться операцией индексации []. Пользовательские операции преобразования типа могут пригодитьсядля работы с типами, реализующими нестандартные представления чисел(арифметика с основанием 100, арифметика чисел с фиксированной точкой,представление в двоично-десятичной записи и т.д.). При этом обычноприходится переопределять такие операции, как + и *. Особенно полезными функции преобразования типа оказываются для работы с такими структурами данных, для которых чтение (реализованное как операция преобразования) является тривиальным, а присваивание и инициализация существенно более сложные операции. Функции преобразования нужны для типов istream и ostream, чтобы стали возможными, например, такие операторы: while (cin>>x) cout<<x; Операция ввода cin>>x возвращает значение istream&. Оно неявно преобразуется в значение, показывающее состояние потока cin, которое затем проверяется в операторе while (см. $$10.3.2). Но все-таки определять неявное преобразование типа, при котором можно потерять преобразуемое значение, как правило, плохое решение. Вообще, лучше экономно пользоваться операциями преобразования. Избыток таких операций может вызывать большое число неоднозначностей. Транслятор обнаруживает эти неоднозначности, но разрешить их может быть совсем непросто. Возможно вначале лучше для преобразований использовать поименованные функции, например, X::intof(), и только после того, как такую функцию как следуют опробуют, и явное преобразование типа будет сочтено неэлегантным решением, можно заменить операторной функцией преобразования X::operator int().
Неоднозначности
Присваивание или инициализация объекта класса X является законным, если присваиваемое значение имеет тип X, или если существует единственное преобразование его в значение типа X. В некоторых случаях значение нужного типа строится с помощью повторных применений конструкторов или операций преобразования. Это должно задаваться явным образом, допустимо неявное пользовательское преобразование только одного уровня вложенности. В некоторых случаях существует несколько способов построения значения нужного типа, но это является незаконным. Приведем пример: class x { /*... */ x(int); x(char*); }; class y { /*... */ y(int); }; class z { /*... */ z(x); }; x f(x); y f(y); z g(z); void k1() { f(1); // недопустимо, неоднозначность: f(x(1)) или f(y(1)) f(x(1)); f(y(1)); g("asdf"); // недопустимо, g(z(x("asdf"))) не используется } Пользовательские преобразования типа рассматриваются только в томслучае, когда без них нельзя однозначно выбрать вызываемую функцию: class x { /*... */ x(int); }; void h(double); void h(x); void k2() { h(1); } Вызов h(1) можно интерпретировать либо как h(double(1)), либо как h(x(1)), поэтому в силу требования однозначности его можно счесть незаконным. Но поскольку в первой интерпретации используется только стандартное преобразование, то по правилам, указанным в $$4.6.6 и $$R.13.2, выбирается оно. Правила на преобразования типа не слишком просто сформулировать и реализовать, не обладают они и достаточной общностью. Рассмотрим требование единственности законного преобразования. Проще всего разрешить транслятору применять любое преобразование, которое он сумеет найти. Тогда для выяснения корректности выражения не нужно рассматривать все существующие преобразования. К сожалению, в таком случае поведение программы будет зависеть от того, какое именно преобразование найдено. В результате поведение программы будет зависеть от порядка описаний преобразований. Поскольку часто эти описания разбросаны по разным исходным файлам (созданным, возможно, разными программистами), то результат программы будет зависеть в каком порядке эти файлы сливаются в программу. С другой стороны, можно вообще запретить неявные преобразования, и это самое простое решение. Но результатом будет некачественный интерфейс, определяемый пользователем, или взрывной рост перегруженных функций и операций, что мы и видели на примере класса complex из предыдущего раздела. При самом общем подходе учитываются все сведения о типах и рассматриваются все существующие преобразования. Например, с учетом приведенных описаний в присваивании aa=f(1) можно разобраться с вызовом f(1), поскольку тип aa задает единственное преобразование. Если aa имеет тип x, то единственным преобразованием будет f(x(1)), поскольку только оно дает нужный для левой части тип x. Если aa имеет тип y, будет использоваться f(y(1)). При самом общем подходе удается разобраться и с вызовом g("asdf"), поскольку g(z(x("asdf))) является его единственной интерпретацией. Трудность этого подхода в том, что требуется доскональный разбор всего выражения, чтобы установить интерпретацию каждой операции и вызова функции. В результате трансляция замедляется, вычисление выражения может произойти странным образом и появляются загадочные сообщения об ошибках, когда транслятор учитывает определенные в библиотеках преобразования и т.д. В результате транслятору приходится учитывать больше информации, чем известно самому программисту! Выбран подход, при котором проверка является строго восходящим процессом, когда в каждый момент рассматривается только одна операция с операндами, типы которых уже прошли проверку. Требование строго восходящего разбора выражения предполагает, что тип возвращаемого значения не учитывается при разрешении перегрузки: class quad { //... public: quad(double); //... }; quad operator+(quad,quad); void f(double a1, double a2) { quad r1 = a1+a2; // сложение с двойной точностью quad r2 = quad(a1)+a2; // вынуждает использовать // операции с типами quad } В проектировании языка делался расчет на строго восходящий разбор, поскольку он более понятный, а кроме того, не дело транслятора решать такие вопросы, какую точность для сложения желает программист. Однако, надо отметить, что если определились типы обеих частей в присваивании и инициализации, то для их разрешения используется они оба: class real { //... public: operator double(); operator int(); //... }; void g(real a) { double d = a; // d = a.double(); int i = a; // i = a.int(); d = a; // d = a.double(); i = a; // i = a.int(); } В этом примере выражения все равно разбираются строго восходящим методом, когда в каждый момент рассматриваются только одна операция и типы ее операндов.
Литералы
Для классов нельзя определить литеральные значения, подобному тому как 1.2 и 12e3 являются литералами типа double. Однако, для интерпретации значений классов могут использоваться вместо функций-членов литералы основных типов. Общим средством для построения таких значений служат конструкторы с единственным параметром. Если конструктор достаточно простой и реализуется подстановкой, вполне разумно представлять его вызов как литерал. Например, с учетом описания класса complex в <complex.h> в выражении zz1*3+zz2*complex(1,2) произойдет два вызова функций, а не пять. Две операции * приведут к вызову функции, а операция + и вызовы конструктора для построения complex(3) и complex(1,2) будут реализованы подстановкой.
Большие объекты