Бьерн Страуструп (947334), страница 40

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

Текст из файла (страница 40)

Особенно полезными функции преобразования типа оказываются для

работы с такими структурами данных, для которых чтение (реализованное

как операция преобразования) является тривиальным, а присваивание и

инициализация существенно более сложные операции.

Функции преобразования нужны для типов istream и ostream, чтобы

стали возможными, например, такие операторы:

while (cin>>x) cout<<x;

Операция ввода cin>>x возвращает значение istream&. Оно неявно

преобразуется в значение, показывающее состояние потока cin, которое

затем проверяется в операторе while (см. $$10.3.2). Но все-таки

определять неявное преобразование типа, при котором можно потерять

преобразуемое значение, как правило, плохое решение.

Вообще, лучше экономно пользоваться операциями преобразования.

Избыток таких операций может вызывать большое число неоднозначностей.

Транслятор обнаруживает эти неоднозначности, но разрешить их может

быть совсем непросто. Возможно вначале лучше для преобразований

использовать поименованные функции, например, X::intof(), и только

после того, как такую функцию как следуют опробуют, и явное

преобразование типа будет сочтено неэлегантным решением, можно

заменить операторной функцией преобразования X::operator int().

7.3.3 Неоднозначности

Присваивание или инициализация объекта класса 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();

}

В этом примере выражения все равно разбираются строго восходящим

методом, когда в каждый момент рассматриваются только одна операция

и типы ее операндов.

7.4 Литералы

Для классов нельзя определить литеральные значения, подобному

тому как 1.2 и 12e3 являются литералами типа double. Однако,

для интерпретации значений классов могут использоваться вместо

функций-членов литералы основных типов. Общим средством для

построения таких значений служат конструкторы с единственным

параметром. Если конструктор достаточно простой и реализуется

подстановкой, вполне разумно представлять его вызов как

литерал. Например, с учетом описания класса complex в <complex.h>

в выражении zz1*3+zz2*complex(1,2) произойдет два вызова функций,

а не пять. Две операции * приведут к вызову функции, а операция

+ и вызовы конструктора для построения complex(3) и complex(1,2)

будут реализованы подстановкой.

7.5 Большие объекты

При выполнении любой бинарной операции для типа complex реализующей

эту операцию функции будут передаваться как параметры копии обоих

операндов. Дополнительные расходы, вызванные копированием двух

значений типа double, заметны, хотя по всей видимости допустимы.

К сожалению представление не всех классов является столь удобно

компактным. Чтобы избежать избыточного копирования, можно

определять функции с параметрами типа ссылки:

class matrix {

double m[4][4];

public:

matrix();

friend matrix operator+(const matrix&, const matrix&);

friend matrix operator*(const matrix&, const matrix&);

};

Ссылки позволяют без излишнего копирования использовать

выражения с обычными арифметическими операциями и для больших

объектов. Указатели для этой цели использовать нельзя, т.к.

невозможно переопределить интерпретацию операции, если она

применяется к указателю. Операцию плюс для матриц можно определить

так:

matrix operator+(const matrix& arg1, const& arg2)

{

matrix sum;

for (int i = 0; i<4; i++)

for (int j=0; j<4; j++)

sum.m[i] [j] = arg1.m[i][j] + arg2.m[i][j];

return sum;

}

Здесь в функции operator+() операнды выбираются по ссылке, а

возвращается само значение объекта. Более эффективным решением

был бы возврат тоже ссылки:

class matrix {

// ...

friend matrix& operator+(const matrix&, const matrix&);

friend matrix& operator*(const matrix&, const matrix&);

};

Это допустимо, но возникает проблема с выделением памяти. Поскольку

ссылка на результат операции будет передаваться как ссылка на

возвращаемое функцией значение, оно не может быть автоматической

переменной этой функции. Поскольку операция может использоваться

неоднократно в одном выражении, результат не может быть и

локальной статической переменной. Как правило, результат будет

записываться в отведенный в свободной памяти объект. Обычно

бывает дешевле (по затратам на время выполнения и память данных

и команд) копировать результирующее значение, чем размещать его

в свободной памяти и затем в конечном счете освобождать выделенную

память. К тому же этот способ проще запрограммировать.

7.6 Присваивание и инициализация

Рассмотрим простой строковый класс string:

struct string {

char* p;

int size; // размер вектора, на который указывает p

string(int size) { p = new char[size=sz]; }

~string() { delete p; }

};

Строка - это структура данных, содержащая указатель на вектор

символов и размер этого вектора. Вектор создается конструктором и

удаляется деструктором. Но как мы видели в $$5.5.1 здесь могут

возникнуть проблемы:

void f()

{

string s1(10);

string s2(20)

s1 = s2;

}

Здесь будут размещены два символьных вектора, но в результате

присваивания s1 = s2 указатель на один из них будет уничтожен,

и заменится копией второго. По выходе из f() будет вызван для s1

и s2 деструктор, который дважды удалит один и тот же вектор,

результаты чего по всей видимости будут плачевны. Для решения

этой проблемы нужно определить соответствующее присваивание

объектов типа string:

struct string {

char* p;

int size; // размер вектора, на который указывает p

string(int size) { p = new char[size=sz]; }

~string() { delete p; }

string& operator=(const string&);

};

string& string::operator=(const string& a)

{

if (this !=&a) { // опасно, когда s=s

delete p;

p = new char[size=a.size];

strcpy(p,a.p);

}

return *this;

}

При таком определении string предыдущий пример пройдет как

задумано. Но после небольшого изменения в f() проблема возникает

снова, но в ином обличии:

void f()

{

string s1(10);

string s2 = s1; // инициализация, а не присваивание

}

Теперь только один объект типа string строится конструктором

string::string(int), а уничтожаться будет две строки. Дело в

том, что пользовательская операция присваивания не применяется

к неинициализированному объекту. Достаточно взглянуть на функцию

string::operator(), чтобы понять причину этого: указатель p

будет тогда иметь неопределенное, по сути случайное значение.

Как правило, в операции присваивания предполагается, что ее

параметры проинициализированы. Для инициализации типа той, что

приведена в этом примере это не так по определению. Следовательно,

чтобы справиться с инициализацией нужна похожая, но своя функция:

Характеристики

Список файлов книги