Стенли Липпман - Язык программирования C++. Пятое издание

// если move возвращает Screen, а не Screen&

Screen temp = myScreen.move(4,0); // возвращаемое значение было

// бы скопировано

temp.set('#'); // содержимое myScreen осталось бы неизменно

Если бы функция move()имела возвращаемое значение не ссылочного типа, то оно было бы копией *this(см. раздел 6.3.2). Вызов функции set()изменил бы лишь временную копию, а не сам объект myScreen.

Теперь добавим функцию display(), выводящую содержимое окна. Необходима возможность включать эту операцию в последовательность операций set()и move(). Поэтому, подобно функциям set()и move(), функция display()возвратит ссылку на объект, для которого она выполняется.

Логически отображение объекта класса Screen(окна) не изменяет его, поэтому функцию display()следует сделать константным членом. Но если функция display()будет константной, то thisбудет указателем на константу, а значение *this— константным объектом. Следовательно, типом возвращаемого значения функции display()будет const Screen&. Однако, если функция display()возвратит ссылку на константу, мы не сможем вставить вызов функции display()в последовательность действий:

Screen myScreen;

// если display возвращает константную ссылку,

// вызов в последовательности будет ошибкой

myScreen.display(cout).set('*');

Хотя объект myScreen неконстантный, вызов функции set()не будет компилироваться. Проблема в том, что константная версия функции display()возвращает ссылку на константу, и мы не можем вызвать функцию set()для константного объекта.

Тип возвращаемого значения константной функции-члена, возвращающей *thisкак ссылку, должен быть ссылкой на константу.

Функции-члены вполне можно перегружать исходя из того, являются ли они константными или нет, причем по тем же причинам, по которым функцию можно перегружать исходя из того, является ли ее параметр указателем на константу (см. раздел 6.4). Неконстантная версия неприменима для константных объектов; она применима только для константных объектов. Для неконстантного объекта можно вызвать любую версию, но неконстантная версия будет лучшим соответствием.

В этом примере определим закрытую функцию-член do_display()для фактического вывода окна. Каждая из функций display()вызовет эту функцию, а затем возвратит объект, для которого она выполняется:

class Screen {

public:

// display перегружена на основании того, является ли

// объект константой или нет

Screen &display(std::ostream &os)

{ do_display(os); return *this; }

const Screen &display(std::ostream &os) const

{ do_display(os); return *this; }

private:

// функция отображения окна

void do_display(std::ostream &os) const {os << contents;}

// другие члены как прежде

};

Как и в любом другом случае, при вызове одной функции-члена другой неявно передается указатель this. Таким образом, когда функция display()вызывает функцию-член do_display(), ей неявно передается собственный указатель this. Когда неконстантная версия функции display()вызывает функцию do_display(), ее указатель thisнеявно преобразуется из указателя на неконстанту в указатель на константу (см. раздел 4.11.2).

Когда функция do_display()завершает работу, функция display()возвращает объект, с которым они работают, обращаясь к значению указателя this. В неконстантной версии указатель thisуказывает на неконстантный объект, так что эта версия функции display()возвращает обычную, неконстантную ссылку; константная версия возвращает ссылку на константу.

Когда происходит вызов функции display()для объекта, вызываемую версию определяет его константность:

Screen myScreen(5, 3);

const Screen blank(5, 3);

myScreen.set('#').display(cout); // вызов неконстантной версии

blank.display(cout); // вызов константной версии

Некоторые читатели могут удивиться: зачем дополнительно создавать отдельную функцию do_display()? В конце концов, обращение к функции do_display()не намного проще, чем осуществляемое в ней действие.

Зачем же она нужна? Причин здесь несколько.

• Всегда желательно избегать нескольких экземпляров одного кода.

• По мере развития класса функция display()может стать значительно более сложной, а следовательно, преимущества одной, а не нескольких копий кода станут более очевидными.

• Во время разработки в тело функции display(), вероятно, придется добавить отладочный код, который в финальной версии будет удален. Это будет проще сделать в случае, когда весь отладочный код находится в одной функции do_display().

• Поскольку функция do_display()объявлена встраиваемой ( inline), при создании исполняемого кода компилятор и так вставит ее содержимое по месту вызова, поэтому вызов функции не повлечет за собой никаких потерь времени и ресурсов.

Обычно в хорошо спроектированных программах на языке С++ присутствует множество маленьких функций, таких как do_display(), которые выполняют всю основную работу, когда их использует набор других функций.

Упражнение 7.27. Добавьте функции move(), set()и display()в свою версию класса Screen. Проверьте свой класс, выполнив следующий код:

Screen myScreen(5, 5, 'X');

myScreen.move(4,0).set('#').display(cout);

cout << "\n";

myScreen.display(cout);

cout << "\n";

Упражнение 7.28. Что если бы в предыдущем упражнении типом возвращаемого значения функций move(), set()и display()был Screen, а не Screen&?

Упражнение 7.29. Пересмотрите свой класс Screenтак, чтобы функции move(), set()и display()возвращали тип Screen, а затем проверьте свое предположение из предыдущего упражнения.

Упражнение 7.30. Обращение к членам класса при помощи указателя thisвполне допустимо, но избыточно. Обсудите преимущества и недостатки явного использования указателя thisдля доступа к членам.

Каждый класс определяет уникальный тип. Два различных класса определяют два разных типа, даже если их члены совпадают. Например:

struct First {

int memi;

int getMem();

};

struct Second {

int memi;

int getMem();