Программирование. Принципы и практика использования C++ Исправленное издание

Страуструп Бьерн

}

}

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

Обратите внимание на то, что наше решение осталось незавершенным: функция

get_int

без указания диапазона осталась “болтушкой”. Более тонкий аспект этой проблемы заключается в том, что вспомогательные функции, используемые в разных частях программы, не должны содержать “вшитых” сообщений. Далее, библиотечные функции, которые по своей сути предназначены для использования во многих

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

error

не выводит никаких сообщений об ошибках (см. раздел 5.6.3); в общем, мы не можем знать, куда их писать.

10.8. Операторы вывода, определенные пользователем

Определение оператора вывода

<<

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

<<

для типа, определенного пользователем. В ходе отладки и на первых этапах проектирования нам нужно хотя бы просто записывать объекты, имеющие указанный тип. Позднее нам может понадобиться более сложный оператор вывода

<<

, позволяющий пользователю получать форматированную информацию. Кроме того, если представление выходной информации отличается от стандартного представления, обеспечиваемого обычным оператором

<<

, мы можем просто обойти этот оператор и записывать отдельные части объектов пользовательского типа так, как мы хотим.

Рассмотрим простой оператор вывода для типа

Date

из раздела 9.8, который просто печатает год, месяц и день, разделенные запятыми.

ostream& operator<<(ostream& os, const Date& d)

{

return os << '(' << d.year

<< ',' << d.month

<< ',' << d.day << ')';

}

Таким образом, дата 30 августа 2004 года будет представлена как

(204,8,30)

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

В разделе 9.6 мы упоминали о том, что оператор, определенный пользователем, выполняется с помощью вызова соответствующей функции. Рассмотрим пример. Если в программе определен оператор вывода

<<

для типа

Date

, то инструкция

cout<<d1;

где объект

d1

имеет тип

Date

, эквивалентна вызову функции

operator<<(cout,d1);

Обратите внимание на то, что первый аргумент

ostream&

функции

operator<<

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

cout<<d1<<d2;

В этом случае сначала был бы выполнен первый оператор

<<

, а затем второй.

cout << d1 << d2; // т.е. operator<<(cout,d1) << d2;

// т.е. operator<<(operator<<(cout,d1),d2);

Иначе говоря,

сначала происходит первый вывод объекта

d1

в поток

cout

, а затем вывод объекта

d2

в поток вывода, являющийся результатом выполнения первого оператора. Фактически мы можем использовать любой из указанных трех вариантов вывода объектов

d1

и

d2

. Однако один из этих вариантов намного проще остальных.

10.9. Операторы ввода, определенные пользователем

Определение оператора ввода

>>

для заданного типа и формат ввода обычно тесно связаны с обработкой ошибок. Следовательно, эта задача может оказаться довольной сложной.

Рассмотрим простой оператор ввода для типа

Date

из раздела 9.8, который считывает даты, ранее записанные с помощью оператора

<<

, определенного выше.

istream& operator>>(istream& is, Date& dd)

{

int y, m, d;

char ch1, ch2, ch3, ch4;

is >> ch1 >> y >> ch2 >> m >> ch3 >> d >> ch4;

if (!is) return is;

if (ch1!='(' || ch2!=',' || ch3!=',' || ch4!=')') { // ошибка

// формата

is.clear(ios_base::failbit);

return is;

}

dd = Date(y,Date::Month(m),d); // обновляем объект dd

return is;

}

Этот оператор

>>

вводит такие тройки, как

(2004,8,20)

, и пытается создать объект типа

Date

из заданных трех чисел. Как правило, выполнить ввод данных намного труднее, чем их вывод. Просто при вводе данных намного больше возможностей для появления ошибок, чем при выводе.

Если данный оператор

>>

не находит трех чисел, заданных в формате (целое, целое, целое), то поток ввода перейдет в одно из состояний,

fail

,

eof

или

bad

, а целевой объект типа

Date

останется неизмененным. Для установки состояния потока

istream

используется функция-член

clear

. Очевидно, что флаг

ios_base::failbit

переводит поток в состояние

fail

. В идеале при сбое во время чтения следовало бы оставить объект класса

Date

без изменений; это привело бы к более ясному коду. В идеале хотелось бы, чтобы функция

operator>>

отбрасывала любые символы, которые она не использует, но в данном случае это было бы слишком трудно сделать: мы должны были бы прочитать слишком много символов, пока не обнаружится ошибка формата. В качестве примера рассмотрим тройку

(2004, 8, 30}

. Только когда мы увидим закрывающую фигурную скобку,

}

, обнаружится ошибка формата, и нам придется вернуть в поток много символов. Функция

unget

позволяет вернуть только один символ. Если функция

operator>>

считывает неправильный объект класса

Date

, например

(2004,8,32)

, конструктор класса

Date

сгенерирует исключение, которое приведет к прекращению выполнения оператора

operator>>

.

10.10. Стандартный цикл ввода

В разделе 10.5 мы видели, как считываются и записываются файлы. Однако тогда мы еще не рассматривали обработку ошибок (см. раздел 10.6) и считали, что файл считывается от начала до конца. Это разумное предположение, поскольку мы часто отдельно проверяем корректность файла. Тем не менее мы часто хотим выполнять проверку считанных данных в ходе их ввода. Рассмотрим общую стратегию, предполагая, что объект

ist

относится к классу

istream

.