Язык программирования C++ для профессионалов
Неоднозначности
Присваивание или инициализация объекта класса 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))) является его единственной интерпретацией. Трудность этого подхода в том, что требуется доскональный разбор всего выражения, чтобы установить интерпретацию каждой операции и вызова функции. В результате трансляция замедляется, вычисление выражения может произойти странным образом и появляются загадочные сообщения об ошибках, когда транслятор учитывает определенные в библиотеках преобразования и т.д.
В результате транслятору приходится учитывать больше информации, чем известно самому программисту! Выбран подход, при котором проверка является строго восходящим процессом, когда в каждый момент рассматривается только одна операция с операндами, типы которых уже прошли проверку.
Требование строго восходящего разбора выражения предполагает, что тип возвращаемого значения не учитывается при разрешении перегрузки:
