Бьерн Страуструп - Язык программирования С++. Главы 8-10
ОГЛАВЛЕНИЕ
ГЛАВА 8. ШАБЛОНЫТИПА
Вот ваша цитата- Бьерн Страуструп
В этой главе вводится понятие шаблона типа. С его помощью можно достаточно просто определить и реализовать без потерь в эффективности выполнения программы и, не отказываясь от статического контроля типов, такие контейнерные классы, как списки и ассоциативные массивы. Кроме того, шаблоны типа позволяют определить сразу для целого семейства типов обобщенные (генерические) функции, например, такие, как sort (сортировка). В качестве примера шаблона типов и его связи с другими конструкциями языка приводится семейство списочных классов. Чтобы показать способы получения программы из в значительной степени независимых частей, приводится несколько вариантов шаблонной функции sort(). В конце определяется простой шаблон типа для ассоциативного массива и показывается на двух небольших демонстрационных программах, как им пользоваться.
8.1 Введение
Одним из самых полезных видов классов является контейнерный класс, т.е. такой класс, который хранит объекты каких-то других типов. Списки, массивы, ассоциативные массивы и множества - все это контейнерные классы. С помощью описанных в главах 5 и 7 средств можно определить класс, как контейнер объектов единственного, известного типа. Например, в $$5.3.2 определяется множество целых. Но контейнерные классы обладают тем интересным свойством, что тип содержащихся в них объектов не имеет особого значения для создателя контейнера, но для пользователя конкретного контейнера этот тип является существенным. Следовательно, тип содержащихся объектов должен параметром контейнерного класса, и создатель такого класса будет определять его с помощью типа-параметра. Для каждого конкретного контейнера (т.е. объекта контейнерного класса) пользователь будет указывать каким должен быть тип содержащихся в нем объектов. Примером такого контейнерного класса был шаблон типа Vector из $$1.4.3.
В этой главе исследуется простой шаблон типа stack (стек) и в результате вводится понятие шаблонного класса. Затем рассматриваются более полные и правдоподобные примеры нескольких родственных шаблонов типа для списка. Вводятся шаблонные функции и формулируются правила, что может быть параметром таких функций. В конце приводится шаблон типа для ассоциативного массива.
8.2 Простой шаблон типа
Шаблон типа для класса задает способ построения отдельных классов, подобно тому, как описание класса задает способ построения его отдельных объектов. Можно определить стек, содержащий элементы произвольного типа:template<class T>Для простоты не учитывался контроль динамических ошибок. Не считая этого, пример полный и вполне правдоподобный.
class stack {
T* v;
T* p;
int sz;
public:
stack(int s) { v = p = new T[sz=s]; }
~stack() { delete[] v; }
void push(T a) { *p++ = a; }
T pop() { return *--p; }
int size() const { return p-v; }
};
Префикс template<class T> указывает, что описывается шаблон типа с параметром T, обозначающим тип, и что это обозначение будет использоваться в последующем описании. После того, как идентификатор T указан в префиксе, его можно использовать как любое другое имя типа. Область видимости T продолжается до конца описания, начавшегося префиксом template<class T>. Отметим, что в префиксе T объявляется типом, и оно не обязано быть именем класса. Так, ниже в описании объекта sc тип T оказывается просто char.
Имя шаблонного класса, за которым следует тип, заключенный в угловые скобки <>, является именем класса (определяемым шаблоном типа), и его можно использовать как все имена класса. Например, ниже определяется объект sc класса stack<char>:
stack<char> sc(100); // стек символовЕсли не считать особую форму записи имени, класс stack<char> полностью эквивалентен классу определенному так:
class stack_char {
char* v;
char* p;
int sz;
public:
stack_char(int s) { v = p = new char[sz=s]; }
~stack_char() { delete[] v; }
void push(char a) { *p++ = a; }
char pop() { return *--p; }
int size() const { return p-v; }
};Можно подумать, что шаблон типа - это хитрое макроопределение, подчиняющееся правилам именования, типов и областей видимости, принятым в С++. Это, конечно, упрощение, но это такое упрощение, которое помогает избежать больших недоразумений. В частности, применение шаблона типа не предполагает каких-либо средств динамической поддержки помимо тех, которые используются для обычных "ручных" классов. Не следует так же думать, что оно приводит к сокращению программы. Обычно имеет смысл вначале отладить конкретный класс, такой, например, как stack_char, прежде, чем строить на его основе шаблон типа stack<T>. С другой стороны, для понимания шаблона типа полезно представить себе его действие на конкретном типе, например int или shape*, прежде, чем пытаться представить его во всей общности. Имея определение шаблонного класса stack, можно следующим образом определять и использовать различные стеки:
stack<shape*> ssp(200); // стек указателей на фигурыПоскольку все функции-члены класса stack являются подстановками, и в этом примере транслятор создает вызовы функций только для размещения в свободной памяти и освобождения.
stack<Point> sp(400); // стек структур Point
void f(stack<complex>& sc) // параметр типа `ссылка на
// complex'
{
sc.push(complex(1,2));
complex z = 2.5*sc.pop();
stack<int>*p = 0; // указатель на стек целых
p = new stack<int>(800); // стек целых размещается
// в свободной памяти
for ( int i = 0; i<400; i++) {
p->push(i);
sp.push(Point(i,i+400));
}
// ...
}
Функции в шаблоне типа могут и не быть подстановками, шаблонный класс stack с полным правом можно определить и так:
template<class T> class stack {
T* v;
T* p;
int sz;
public:
stack(int);
~stack();
void push(T);
T pop();
int size() const;
};В этом случае определение функции-члена stack должно быть дано где-то в другом месте, как это и было для функций- членов обычных, нешаблонных классов.Подобные функции так же параметризируются типом, служащим параметром для их шаблонного класса, поэтому определяются они с помощью шаблона типа для функции. Если это происходит вне шаблонного класса, это надо делать явно:template<class T> void stack<T>::push(T a)Отметим, что в пределах области видимости имени stack<T> уточнение <T> является избыточным, и stack<T>::stack - имя конструктора.
{
*p++ = a;
}
template<class T> stack<T>::stack(int s)
{
v = p = new T[sz=s];
}
Задача системы программирования, а вовсе не программиста, предоставлять версии шаблонных функций для каждого фактического параметра шаблона типа. Поэтому для приводившегося выше примера система программирования должна создать определения конструкторов для классов stack<shape*>, stack<Point> и stack<int>, деструкторов для stack<shape*> и stack<Point>, версии функций push() для stack<complex>,
stack<int> и stack<Point> и версию функции pop() для stack<complex>. Такие создаваемые функции будут совершенно обычными функциями-членами, например:
void stack<complex>::push(complex a) { *p++ = a; }Здесь отличие от обычной функции-члена только в форме имени класса. Точно так же, как в программе может быть только одно определение функции-члена класса, возможно только одно определение шаблона типа для функции-члена шаблонного класса. Если требуется определение функции-члена шаблонного класса для конкретного типа, то задача системы программирования найти шаблон типа для этой функции-члена и создать нужную версию функции. В общем случае система программирования может рассчитывать на указания от программиста, которые помогут найти нужный шаблон типа. Важно составлять определение шаблона типа таким образом, чтобы его зависимость от глобальных данных была минимальной. Дело в том, шаблон типа будет использоваться для порождения функций и классов на основе заранее неизвестного типа и в неизвестных контекстах. Практически любая, даже слабая зависимость от контекста может проявиться как проблема при отладке программы пользователем, который, вероятнее всего, не был создателем шаблона типа. К совету избегать, насколько это возможно, использований глобальных имен, следует относиться особенно серьезно при разработке шаблона типа.
8.3 Шаблоны типа для списка
На практике при разработке класса, служащего коллекцией объектов, часто приходится учитывать взаимоотношения использующихся в реализации классов, управление памятью и необходимость определить итератор по содержимому коллекции. Часто бывает так, что несколько родственных классов разрабатываются совместно ($$12.2). В качестве примера мы предложим семейство классов, представляющих односвязные списки и шаблоны типа для них.8.3.1 Список с принудительной связью
Вначале определим простой список, в котором предполагается, что в каждом заносимом в список объекте есть поле связи. Потом этот список будет использоваться как строительный материал для создания более общих списков, в которых объект не обязан иметь поле связи. Сперва в описаниях классов будет приведена только общая часть, а реализация будет дана в следующем разделе. Это делается за тем, чтобы вопросы проектирования классов не затемнялись деталями их реализации.Начнем с типа slink, определяющего поле связи в односвязном списке:
struct slink {
slink* next;
slink() { next = 0; }
slink(slink* p) { next = p; }
};Теперь можно определить класс, который может содержать объекты любого, производного от slink, класса: class slist_base {
// ...
public:
int insert(slink*); // добавить в начало списка
int append(slink*); // добавить к концу списка
slink* get(); // удалить и возвратить начало списка
// ...
};Такой класс можно назвать списком с принудительной связью, поскольку его можно использовать только в том случае, когда все элементы имеют поле slink, которое используется как указатель на slist_base. Само имя slist_base (базовый односвязный список) говорит, что этот класс будет использоваться как базовый для односвязных списочных классов. Как обычно, при разработке семейства родственных классов возникает вопрос, как выбирать имена для различных членов семейства. Поскольку имена классов не могут перегружаться, как это делается для имен функций, для обуздания размножения имен перегрузка нам не поможет. Класс slist_base можно использовать так:
void f()Но поскольку структура slink не может содержать никакой информации помимо связи, этот пример не слишком интересен. Чтобы воспользоваться slist_base, надо определить полезный, производный от slink, класс. Например, в трансляторе используются узлы дерева программы name (имя), которые приходится связывать в список:
{
slist_base slb;
slb.insert(new slink);
// ...
slink* p = slb.get();
// ...
delete p;
}
class name : public slink {
// ...
};
void f(const char* s)
{
slist_base slb;
slb.insert(new name(s));
// ...
name* p = (name*)slb.get();
// ...
delete p;
}Здесь все нормально, но поскольку определение класса slist_base дано через структуру slink, приходится использовать явное приведение типа для преобразования значения типа slink*, возвращаемого функцией slist_base::get(), в name*. Это некрасиво. Для большой программы, в которой много списков и производных от slink классов, это к тому же чревато ошибками. Нам пригодилась бы надежная по типу версия класса slist_base:template<class T>Приведение в функции Islist::get() совершенно оправдано и надежно, поскольку в классе Islist гарантируется, что каждый объект в списке действительно имеет тип T или тип производного от T класса. Отметим, что slist_base является частным базовым классом Islist. Мы нет хотим, чтобы пользователь случайно натолкнулся на ненадежные детали реализации. Имя Islist (intrusive singly linked list) обозначает односвязный список с принудительной связью. Этот шаблон типа можно использовать так:
class Islist : private slist_base {
public:
void insert(T* a) { slist_base::insert(a); }
T* get() { return (T*) slist_base::get(); }
// ...
};
void f(const char* s)Попытки некорректного использования будет выявлены на стадии трансляции:
{
Islist<name> ilst;
ilst.insert(new name(s));
// ...
name* p = ilst.get();
// ...
delete p
}
class expr : public slink {
// ...
};
void g(expr* e)
{
Islist<name> ilst;
ilst.insert(e); // ошибка: Islist<name>::insert(),
// а нужно name*
// ...
}Нужно отметить несколько важных моментов относительно нашего примера. Во-первых, решение надежно в смысле типов (преграда тривиальным ошибкам ставится в очень ограниченной части программы, а именно, в функциях доступа из Islist). Во-вторых, надежность типов достигается без увеличения затрат времени и памяти, поскольку функции доступа из Islist тривиальны и реализуются подстановкой. В-третьих, поскольку вся настоящая работа со списком делается в реализации класса slist_base (пока еще не представленной), никакого дублирования функций не происходит, а исходный текст реализации, т.е. функции slist_base, вообще не должен быть доступен пользователю. Это может быть существенно в коммерческом использовании служебных программ для списков. Кроме того, достигается разделение между интерфейсом и его реализацией, и становится возможной смена реализации без перетрансляции программ пользователя. Наконец, простой список с принудительной связью близок по использованию памяти и времени к оптимальному решению. Иными словами, такой подход близок к оптимальному по времени, памяти, упрятыванию данных и контролю типов и в тоже время он обеспечивает большую гибкость и компактность выражений. К сожалению, объект может попасть в Islist только, если он является производным от slink. Значит нельзя иметь список Islist из значений типа int, нельзя составить список из значений какого-то ранее определенного типа, не являющегося производным от slink. Кроме того, придется постараться, чтобы включить объект в два спискаIslist ($$6.5.1).
8.3.2 Список без принудительной связи
После "экскурса" в вопросы построения и использования списка с принудительной связью перейдем к построению списков без принудительной связи. Это значит, что элементы списка не обязаны содержать дополнительную информацию, помогающую в реализации списочного класса. Поскольку мы больше не можем рассчитывать, что объект в списке имеет поле связи, такую связь надо предусмотреть в реализации:template<class T>Класс Tlink<T> хранит копию объектов типа T помимо поля связи, которое идет от его базового класса slink. Отметим, что используется инициализатор в виде info(a), а не присваивание info=a. Это существенно для эффективности операции в случае типов, имеющих нетривиальные конструкторы копирования и операции присваивания ($$7.11). Для таких типов (например, для String) определив конструктор как
struct Tlink : public slink {
T info;
Tlink(const T& a) : info(a) { }
};
Tlink(const T& a) { info = a; }мы получим, что будет строиться стандартный объект String, а уже затем ему будет присваиваться значение. Имея класс, определяющий связь, и класс Islist, получить определение списка без принудительной связи совсем просто:
template<class T>Работать со списком Slist так же просто, как и со списком Ilist. Различие в том, что можно включать в Slist объект, класс которого не является производным от slink, а также можно включать один объект в два списка:
class Slist : private slist_base {
public:
void insert(const T& a)
{ slist_base::insert(new Tlink<T>(a)); }
void append(const T& a)
{ slist_base::append(new Tlink<T>(a)); }
T get();
// ...
};
template<class T>
T Slist<T>::get()
{
Tlink<T>* lnk = (Tlink<T>*) slist_base::get();
T i = lnk->info;
delete lnk;
return i;
}
void f(int i)Однако, список с принудительной связью, например Islist, позволял создавать существенно более эффективную программу и давал более компактное представление. Действительно, при каждом включении объекта в список Slist нужно разместить объект Tlink, а при каждом удалении объекта из Slist нужно удалить объект Tlink, причем каждый раз копируется объект типа T. Когда возникает такая проблема дополнительных расходов, могут помочь два приема. Во-первых, Tlink является прямым кандидатом для размещения с помощью практически оптимальной функции размещения специального назначения (см. $$5.5.6). Тогда дополнительные расходы при выполнении программы сократятся до обычно приемлемого уровня. Во-вторых, полезным оказывается такой прием, когда объекты хранятся в "первичном" списке, имеющим принудительную связь, а списки без принудительной связи используются только, когда требуется включение объекта в несколько списков:
{
Slist<int> lst1;
Slist<int> lst2;
lst1.insert(i);
lst2.insert(i);
// ...
int i1 = lst1.get();
int i2 = lst2.get();
// ...
}
void f(name* p)Конечно, подобные трюки можно делать только в отдельном компоненте программы, чтобы не допустить путаницы списочных типов в интерфейсах различных компонент. Но это именно тот случай, когда ради эффективности и компактности программы на них стоит идти.
{
Islist<name> lst1;
Slist<name*> lst2;
lst1.insert(p); // связь через объект `*p'
lst2.insert(p); // для хранения `p' используется
// отдельный объект типа список
// ...
}
Поскольку конструктор Slist копирует параметр для insert(), список Slist пригоден только для таких небольших объектов, как целые, комплексные числа или указатели.Если для объектов копирование слишком накладно или неприемлемо по смысловым причинам, обычно выход бывает в том, чтобы вместо объектов помещать в список указатели на них. Это сделано в приведенной выше функции f() для
lst2.
Отметим, что раз параметр для Slist::insert() копируется, передача объекта производного класса функции insert(), ожидающей объект базового класса, не пройдет гладко, как можно было (по наивности)
подумать:
class smiley : public circle { /* ... */ };
void g1(Slist<circle>& olist, const smiley& grin)
{
olist.insert(grin); // ловушка!
}В список будет включена только часть circle объекта типа smiley. Отметим, что эта неприятность будет обнаружена транслятором в том случае, который можно считать наиболее вероятным. Так, если бы рассматриваемый базовый класс был абстрактным, транслятор запретил бы "урезание" объекта производного класса:void g2(Slist<shape>& olist, const circle& c)Чтобы избежать "урезания" объекта нужно использовать указатели:
{
olist.insert(c); // ошибка: попытка создать объект
// абстрактного класса
}
void g3(Slist<shape*>& plist, const smiley& grin)Не нужно использовать параметр-ссылку для шаблонного класса:
{
olist.insert(&grin); // прекрасно
}
void g4(Slist<shape&>& rlist, const smiley& grin)При генерации по шаблону типа ссылки, используемые подобным образом, приведут ошибкам в типах. Генерация по шаблону типа для функции
{
rlist.insert(grin); // ошибка: будет созданы команды,
// содержащие ссылку на ссылку (shape&&)
}
Slist::insert(T&);приведет к появлению недопустимой функции
Slist::insert(shape&&);Ссылка не является объектом, поэтому нельзя иметь ссылку на ссылку.
Поскольку список указателей является полезной конструкцией, имеет смысл дать ему специальное имя:
template<class T>Эти определения к тому же улучшают контроль типов и еще больше сокращают необходимость дублировать функции.
class Splist : private Slist<void*> {
public:
void insert(T* p) { Slist<void*>::insert(p); }
void append(T* p) { Slist<void*>::append(p); }
T* get() { return (T*) Slist<void*>::get(); }
};
class Isplist : private slist_base {
public:
void insert(T* p) { slist_base::insert(p); }
void append(T* p) { slist_base::append(p); }
T* get() { return (T*) slist_base::get(); }
};
Часто бывает полезно, чтобы тип элемента, указываемый в шаблоне типа, сам был шаблонным классом. Например, разреженную матрицу, содержащую даты, можно определить так:
typedef Slist< Slist<date> > dates;Обратите внимание на наличие пробелов в этом определении. Если между первой и второй угловой скобкой > нет пробелов, возникнет синтаксическая ошибка, поскольку >> в определении
typedef Slist<Slist<date>> dates;будет трактоваться как операция сдвига вправо. Как обычно, вводимое в typedef имя служит синонимом обозначаемого им типа, а не является новым типом. Конструкция typedef полезна для именования для длинных имен шаблонных классов также, как она полезна для любых других длинных имен типов.
Отметим, что параметр шаблона типа, который может по разному использоваться в его определении, должен все равно указываться среди списка параметров шаблона один раз. Поэтому шаблон типа, в котором используется объект T и список элементов T, надо определять так:
template<class T> class mytemplate {
T ob;
Slist<T> slst;
// ...
};а вовсе не так: template<class T, class Slist<t> > class mytemplate {
T obj;
Slist<T> slst;
// ...
};В $$8.6 и $$R.14.2 даны правила, что может быть параметром шаблона типа.8.3.3 Реализация списка
Реализация функций slist_base очевидна. Единственная трудность связана с обработкой ошибок. Например, что делать если пользователь с помощью функции get() пытается взять элемент из пустого списка. Подобные ситуации разбираются в функции обработки ошибок slist_handler(). Более развитый метод, рассчитанный на особые ситуации, будет обсуждаться в главе 9.Приведем полное описание класса slist_base:
class slist_base {
slink* last; // last->next является началом списка
public:
void insert(slink* a); // добавить в начало списка
void append(slink* a); // добавить в конец списка
slink* get(); // удалить и возвратить
// начало списка
void clear() { last = 0; }
slist_base() { last = 0; }
slist_base(slink* a) { last = a->next = a; }
friend class slist_base_iter;
};Чтобы упростить реализацию обеих функций insert и append, хранится указатель на последний элемент замкнутого списка:void slist_base_insert(slink* a) // добавить в начало спискаЗаметьте, что last->next - первый элемент списка.
{
if (last)
a->next = last->next;
else
last = a;
last->next = a;
}
void slist_base::append(slink* a) // добавить в конец спискаВозможно более гибкое решение, когда slist_handler - указатель на функцию, а не сама функция. Тогда вызов
{
if (last) {
a->next = last->next;
last = last->next = a;
}
else
last = a->next = a;
}
slist* slist_base::get() // удалить и возвратить начало списка
{
if (last == 0)
slist_handler("нельзя взять из пустого списка");
slink* f = last->next;
if (f== last)
last = 0;
else
last->next = f->next;
return f;
}
slist_handler("нельзя взять из пустого списка");будет задаваться так (*slist_handler)(" нельзя взять из пустого списка");Как мы уже делали для функции new_handler ($$3.2.6), полезно завести функцию, которая поможет пользователю создавать свои обработчики ошибок:typedef void (*PFV)(const char*);Особые ситуации, которые обсуждаются в главе 9, не только дают альтернативный способ обработки ошибок, но и способ реализации slist_handler.
PFV set_slist_handler(PFV a)
{
PFV old = slist_handler;
slist_handler = a;
return old;
}
PFV slist_handler = &default_slist_handler;
8.3.4 Итерация
В классе slist_base нет функций для просмотра списка, можно только вставлять и удалять элементы. Однако, в нем описывается как друг класс slist_base_iter, поэтому можно определить подходящий для списка итератор. Вот один из возможных, заданный в том стиле, какой был показан в $$7.8: class slist_base_iter {
slink* ce; // текущий элемент
slist_base* cs; // текущий список
public:
inline slist_base_iter(slist_base& s);
inline slink* operator()()
};
slist_base_iter::slist_base_iter(slist_base& s)
{
cs = &s;
ce = cs->last;
}
slink* slist_base_iter::operator()()
// возвращает 0, когда итерация кончается
{
slink* ret = ce ? (ce=ce->next) : 0;
if (ce == cs->last) ce = 0;
return ret;
}Исходя из этих определений, легко получить итераторы для Slist и Islist. Сначала надо определить дружественные классы для итераторов по соответствующим контейнерным классам:template<class T> class Islist_iter;Обратите внимание, что имена итераторов появляются без определения их шаблонного класса. Это способ определения в условиях взаимной зависимости шаблонов типа.
template<class T> class Islist {
friend class Islist_iter<T>;
// ...
};
template<class T> class Slist_iter;
template<class T> class Slist {
friend class Slist_iter<T>;
// ...
};
Теперь можно определить сами итераторы:
template<class T>Заметьте, что мы опять использовали прием, когда из одного базового класса строится семейство производных классов (а именно, шаблонный класс). Мы используем наследование, чтобы выразить общность классов и избежать ненужного дублирования функций. Трудно переоценить стремление избежать дублирования функций при реализации таких простых и часто используемых классов как списки и итераторы. Пользоваться этими итераторами можно так:
class Islist_iter : private slist_base_iter {
public:
Islist_iter(Islist<T>& s) : slist_base_iter(s) { }
T* operator()()
{ return (T*) slist_base_iter::operator()(); }
};
template<class T>
class Slist_iter : private slist_base_iter {
public:
Slist_iter(Slist<T>& s) : slist_base_iter(s) { }
inline T* operator()();
};
T* Slist_iter::operator()()
{
return ((Tlink<T>*) slist_base_iter::operator()())->info;
}
void f(name* p)Есть несколько способов задать итератор для контейнерного класса. Разработчик программы или библиотеки должен выбрать один из них и придерживаться его. Приведенный способ может показаться слишком хитрым. В более простом варианте можно было просто переименовать operator()() как next(). В обоих вариантах предполагается взаимосвязь между контейнерным классом и итератором для него, так что можно при выполнении итератора обработать случаи, когда элементы добавляются или удаляются из контейнера. Этот и некоторые другие способы задания итераторов были бы невозможны, если бы итератор зависел от функции пользователя, в которой есть указатели на элементы из контейнера. Как правило, контейнер или его итераторы реализуют понятие "установить итерацию на начало" и понятие "текущего элемента".
{
Islist<name> lst1;
Slist<name> lst2;
lst1.insert(p);
lst2.insert(p);
// ...
Islist_iter<name> iter1(lst1);
const name* p;
while (p=iter1()) {
list_iter<name> iter2(lst1);
const name* q;
while (q=iter2()) {
if (p == q) cout << "найден" << *p << '\n';
}
}
}
Если понятие текущего элемента предоставляет не итератор, а сам контейнер, итерация происходит в принудительном порядке по отношению к контейнеру аналогично тому, как поля связи принудительно хранятся в объектах из контейнера. Значит трудно одновременно вести две итерации для одного контейнера, но расходы на память и время при такой организации итерации близки к оптимальным. Приведем пример:
class slist_base {
// ...
slink* last; // last->next голова списка
slink* current; // текущий элемент
public:
// ...
slink* head() { return last?last->next:0; }
slink* current() { return current; }
void set_current(slink* p) { current = p; }
slink* first() { set_current(head()); return current; }
slink* next();
slink* prev();
};Подобно тому, как в целях эффективности и компактности программы можно использовать для одного объекта как список с принудительной связью, так и список без нее, для одного контейнера можно использовать принудительную и непринудительную итерацию:void f(Islist<name>& ilst)Еще один вид итераторов показан в $$8.8.
// медленный поиск имен-дубликатов
{
list_iter<name> slow(ilst); // используется итератор
name* p;
while (p = slow()) {
ilst.set_current(p); // рассчитываем на текущий элемент
name* q;
while (q = ilst.next())
if (strcmp(p->string,q->string) == 0)
cout << "дубликат" << p << '\n';
}
}
8.4 Шаблоны типа для функций
Использование шаблонных классов означает наличие шаблонных функций-членов. Помимо этого, можно определить глобальные шаблонные функции, т.е. шаблоны типа для функций, не являющихся членами класса. Шаблон типа для функций порождает семейство функций точно также, как шаблон типа для класса порождает семейство классов. Эту возможность мы обсудим на последовательности примеров, в которых приводятся варианты функции сортировки sort(). Каждый из вариантов в последующих разделах будет иллюстрировать общий метод. Как обычно мы сосредоточимся на организации программы, а не на разработке ее алгоритма, поэтому использоваться будет тривиальный алгоритм. Все варианты шаблона типа для sort() нужны для того, чтобы показать возможности языка м полезные приемы программирования. Варианты не упорядочены в соответствии с тем, насколько они хороши. Кроме того, можно обсудить и традиционные варианты без шаблонов типа, в частности, передачу указателя на функцию, производящую сравнение.8.4.1 Простой шаблон типа для глобальной функции
Начнем с простейшего шаблона для sort():template<class T> void sort(Vector<T>&);Какая именно функция sort() будет вызываться определяется фактическим параметром. Программист дает определение шаблона типа для функции, а задача системы программирования обеспечить создание правильных вариантов функции по шаблону и вызов соответствующего варианта. Например, простой шаблон с алгоритмом пузырьковой сортировки можно определить так:
void f(Vector<int>& vi,
Vector<String>& vc,
Vector<int>& vi2,
Vector<char*>& vs)
{
sort(vi); // sort(Vector<int>& v);
sort(vc); // sort(Vector<String>& v);
sort(vi2); // sort(Vector<int>& v);
sort(vs); // sort(Vector<char*>& v);
}
template<class T> void sort(Vector<T>& v)Советуем сравнить это определение с функцией сортировки с тем же алгоритмом из $$4.6.9. Существенное отличие этого варианта в том, что вся необходимая информация передается в единственном параметре
/*
Сортировка элементов в порядке возрастания
Используется сортировка по методу пузырька
*/
{
unsigned n = v.size();
for (int i=0; i<n-1; i++)
for (int j=n-1; i<j; j--)
if (v[j] < v[j-1]) { // меняем местами v[j] и v[j-1]
T temp = v[j];
v[j] = v[j-1];
v[j-1] = temp;
}
}
v. Поскольку тип сортируемых элементов известен (из типа фактического параметра, можно непосредственно сравнивать элементы, а не передавать указатель на производящую сравнение функцию. Кроме того, нет нужды возиться с операцией sizeof. Такое решение кажется более красивым и к тому же оно более эффективно, чем обычное. Все же оно сталкивается с трудностью. Для некоторых типов операция < не определена, а для других, например char*, ее определение противоречит тому, что требуется в приведенном определении шаблонной функции. (Действительно, нам нужно сравнивать не указатели на строки, а сами строки). В первом случае попытка создать вариант sort() для таких типов закончится неудачей (на что и следует надеяться) , а во втором появиться функция, производящая неожиданный результат.
Чтобы правильно сортировать вектор из элементов char* мы можем просто задать самостоятельно подходящее определение функции sort(Vector<char*>&):
void sort(Vector<char*>& v)Поскольку для векторов из указателей на строки пользователь дал свое особое определение функции sort(), оно и будет использоваться, а создавать для нее определение по шаблону с параметром типа
{
unsigned n = v.size();
for (int i=0; i<n-1; i++)
for ( int j=n-1; i<j; j--)
if (strcmp(v[j],v[j-1])<0) {
// меняем местами v[j] и v[j-1]
char* temp = v[j];
v[j] = v[j-1];
v[j-1] = temp;
}
}
Vector<char*>& не нужно. Возможность дать для особо важных или "необычных" типов свое определение шаблонной функции дает ценное качество гибкости в программировании и может быть важным средством доведения программы до оптимальных характеристик.
8.4.2 Производные классы позволяют ввести новые операции
В предыдущем разделе функция сравнения была "встроенной" в теле sort() (просто использовалась операция <). Возможно другое решение, когда ее предоставляет сам шаблонный класс Vector. Однако, такое решение имеет смысл только при условии, что для типов элементов возможно осмысленное понятие сравнения. Обычно в такой ситуации функцию sort() определяют только для векторов, на которых определена операция < :template<class T> void sort(SortableVector<T>& v)Класс SortableVector (сортируемый вектор) можно определить так:
{
unsigned n = v.size();
for (int i=0; i<n-1; i++)
for (int j=n-1; i<j; j--)
if (v.lessthan(v[j],v[j-1])) {
// меняем местами v[j] и v[j-1]
T temp = v[j];
v[j] = v[j-1];
v[j-1] = temp;
}
}
template<class T> class SortableVectorЧтобы это определение имело смысл еще надо определить шаблонный класс Comparator (сравниватель):
: public Vector<T>, public Comparator<T> {
public:
SortableVector(int s) : Vector<T>(s) { }
};
template<class T> class Comparator {
public:
inline static lessthan(T& a, T& b) // функция "меньше"
{ return strcmp(a,b)<0; }
// ...
};Чтобы устранить тот эффект, что в нашем случае операция < дает не тот результат для типа char*, мы определим специальный вариант класса сравнивателя: class Comparator<char*> {
public:
inline static lessthan(const char* a, const char* b)
// функция "меньше"
{ return strcmp(a,b)<0; }
// ...
};Описание специального варианта шаблонного класса для char* полностью подобно тому, как в предыдущем разделе мы определили специальный вариант шаблонной функции для этой же цели. Чтобы описание специального варианта шаблонного класса сработало, транслятор должен обнаружить его до использования. Иначе будет использоваться создаваемый по шаблону класс. Поскольку класс должен иметь в точности одно определение в программе, использовать и специальный вариант класса, и вариант, создаваемый по шаблону, будет ошибкой. Поскольку у нас уже специальный вариант класса Comparator для char*, специальный вариант класса SortableVector для char* не нужен, и можем, наконец, попробовать сортировку:
void f(SortableVector<int>& vi,Возможно иметь два вида векторов и не очень хорошо, но, по крайней мере, SortableVector является производным от Vector. Значит если в функции не нужна сортировка, то в ней и не надо знать о классе
SortableVector<String>& vc,
SortableVector<int>& vi2,
SortableVector<char*>& vs)
{
sort(vi);
sort(vc);
sort(vi2);
sort(vs);
}
SortableVector, а там, где нужно, сработает неявное преобразование ссылки на производный класс в ссылку на общий базовый класс. Мы ввели производный от Vector и Comparator класс SortableVector
(вместо того, чтобы добавить функции к классу, производному от одного Vector) просто потому, что класс Comparator уже напрашивался в предыдущим примере. Такой подход типичен при создании больших библиотек. Класс Comparator естественный кандидат для библиотеки, поскольку в нем можно указать различные требования к операциям сравнения для разных типов.
8.4.3 Передача операций как параметров функций
Можно не задавать функцию сравнения как часть типа Vector, а передавать ее как второй параметр функции sort(). Этот параметр является объектом класса, в котором определена реализация операции сравнения:template<class T> void sort(Vector<T>& v, Comparator<T>& cmp)Этот вариант можно рассматривать как обобщение традиционного приема, когда операция сравнения передается как указатель на функцию. Воспользоваться этим можно так:
{
unsigned n = v.size();
for (int i = 0; i<n-1; i++)
for ( int j = n-1; i<j; j--)
if (cmp.lessthan(v[j],v[j-1])) {
// меняем местами v[j] и v[j-1]
T temp = v[j];
v[j] = v[j-1];
v[j-1] = temp;
}
}
void f(Vector<int>& vi,Отметим, что включение в шаблон класса Comparator как параметра гарантирует, что функция lessthan будет реализовываться подстановкой. В частности, это полезно, если в шаблонной функции используется несколько функций, а не одна операция сравнения, и особенно это полезно, когда эти функции зависят от хранящихся в том же объекте данных.
Vector<String>& vc,
Vector<int>& vi2,
Vector<char*>& vs)
{
Comparator<int> ci;
Comparator<char*> cs;
Comparator<String> cc;
sort(vi,ci); // sort(Vector<int>&);
sort(vc,cc); // sort(Vector<String>&);
sort(vi2,ci); // sort(Vector<int>&);
sort(vs,cs); // sort(Vector<char*>&);
}
8.4.4 Неявная передача операций
В примере из предыдущего раздела объекты Comparator на самом деле никак не использовались в вычислениях. Это просто "искусственные" параметры, нужные для правильного контроля типов. Введение таких параметров достаточно общий и полезный прием, хотя и не слишком красивый. Однако, если объект используется только для передачи операции (как и было в нашем случае), т.е. в вызываемой функции не используется ни значение, ни адрес объекта, то можно вместо этого передавать операцию неявно:template<class T> void sort(Vector<T>& v)В результате мы приходим к первоначальному варианту использования sort():
{
unsigned n = v.size();
for (int i=0; i<n-1; i++)
for (int j=n-1; i<j; j--)
if (Comparator<T>::lessthan(v[j],v[j-1])) {
// меняем местами v[j] и v[j-1]
T temp = v[j];
v[j] = v[j-1];
v[j-1] = temp;
}
}
void f(Vector<int>& vi,Основное преимущество этого варианта, как и двух предыдущих, по сравнению с исходным вариантом в том, что часть программы, занятая собственно сортировкой, отделена от частей, в которых находятся такие операции, работающие с элементами, как, например lessthan. Необходимость подобного разделения растет с ростом программы, и особенный интерес это разделение представляет при проектировании библиотек. Здесь создатель библиотеки не может знать типы параметров шаблона, а пользователи не знают (или не хотят знать) специфику используемых в шаблоне алгоритмов. В частности, если бы в функции
Vector<String>& vc,
Vector<int>& vi2,
Vector<char*>& vs)
{
sort(vi); // sort(Vector<int>&);
sort(vc); // sort(Vector<String>&);
sort(vi2); // sort(Vector<int>&);
sort(vs); // sort(Vector<char*>&);
}
sort() использовался более сложный, оптимизированный и рассчитанный на коммерческое применение алгоритм, пользователь не очень бы стремился написать свою особую версию для типа char*, как это было сделано в $$8.4.1. Хотя реализация класса Comparator для специального случая char* тривиальна и может использоваться и в других ситуациях.
8.4.5 Введение операций с помощью параметров шаблонного класса
Возможны ситуации, когда неявность связи между шаблонной функцией sort() и шаблонным классом Comparator создает трудности. Неявную связь легко упустить из виду и в то же время разобраться в ней может быть непросто. Кроме того, поскольку эта связь "встроена" в функцию sort(), невозможно использовать эту функцию для сортировки векторов одного типа, если операция сравнения рассчитана на другой тип (см. упражнение 3 в $$8.9). Поместив функцию sort() в класс, мы можем явно задавать связь с классом Comparator: template<class T, class Comp> class Sort {
public:
static void sort(Vector<T>&);
};Не хочется повторять тип элемента, и это можно не делать, если использовать typedef в шаблоне Comparator: template<class T> class Comparator {
public:
typedef T T; // определение Comparator<T>::T
static int lessthan(T& a, T& b) {
return a < b;
}
// ...
};В специальном варианте для указателей на строки это определение выглядит так: class Comparator<char*> {
public:
typedef char* T;
static int lessthan(T a, T b) {
return strcmp(a,b) < 0;
}
// ...
};После этих изменений можно убрать параметр, задающий тип элемента, из класса Sort: template<class T, class Comp> class Sort {
public:
static void sort(Vector<T>&);
};Теперь можно использовать сортировку так:void f(Vector<int>& vi,и определить функцию sort() следующим образом:
Vector<String>& vc,
Vector<int>& vi2,
Vector<char*>& vs)
{
Sort< int,Comparator<int> >::sort(vi);
Sort< String,Comparator<String> >:sort(vc);
Sort< int,Comparator<int> >::sort(vi2);
Sort< char*,Comparator<char*> >::sort(vs);
}
template<class T, class Comp>Последний вариант ярко демонстрирует как можно соединять в одну программу отдельные ее части. Этот пример можно еще больше упростить, если использовать класс сравнителя (Comp) в качестве единственного параметра шаблона. В этом случае в определениях класса Sort и функции Sort::sort() тип элемента будет обозначаться как Comp::T.
void Sort<T,Comp>::sort(Vector<T>& v)
{
for (int i=0; i<n-1; i++)
for (int j=n-1; i<j; j--)
if (Comp::lessthan(v[j],v[j-1])) {
T temp = v[j];
v[j] = v[j-1];
v[j-1] = temp;
}
}
8.5 Разрешение перегрузки для шаблонной функции
К параметрам шаблонной функции нельзя применять никаких преобразований типа. Вместо этого при необходимости создаются новые варианты функции:template<class T> T sqrt(t);Здесь для всех трех типов параметров будет создаваться по шаблону своя функция sqrt. Если пользователь захочет чего-нибудь иного, например вызвать sqrt(double), задавая параметр int, нужно использовать явное преобразование типа:
void f(int i, double d, complex z)
{
complex z1 = sqrt(i); // sqrt(int)
complex z2 = sqrt(d); // sqrt(double)
complex z3 = sqrt(z); // sqrt(complex)
// ...
}
template<class T> T sqrt(T);В этом примере по шаблону будут создаваться определения только для sqrt(double) и sqrt(complex).
void f(int i, double d, complex z)
{
complex z1 = sqrt(double(i)); // sqrt(double)
complex z2 = sqrt(d); // sqrt(double)
complex z3 = sqrt(z); // sqrt(complex)
// ...
}
Шаблонная функция может перегружаться как простой, так и шаблонной функцией того же имени. Разрешение перегрузки как шаблонных, так и обычных функций с одинаковыми именами происходит за три шага. Эти правила слишком строгие, и, по всей видимости будут ослаблены, чтобы разрешить преобразования ссылок и указателей, а, возможно, и другие стандартные преобразования. Как обычно, при таких преобразованиях будет действовать контроль однозначности.
[1] Найти функцию с точным сопоставлением параметров ($$R.13.2); если такая есть, вызвать ее.
[2] Найти шаблон типа, по которому можно создать вызываемую функцию с точным сопоставлением параметров; если такая есть, вызвать ее.
[3] Попробовать правила разрешения для обычных функций ($$r13.2); если функция найдена по этим правилам, вызвать ее, иначе вызов является ошибкой.
В любом случае, если на первом шаге найдено более одной функции, вызов считается неоднозначным и является ошибкой. Например:
template<class T>Поскольку до генерации функции по шаблону не применяется никаких преобразований типа (правило [2]), последний вызов в этом примере нельзя разрешить как max(a,int(c)). Это может сделать сам пользователь, явно описав функцию max(int,int). Тогда вступает в силу правило [3]:
T max(T a, T b) { return a>b?a:b; };
void f(int a, int b, char c, char d)
{
int m1 = max(a,b); // max(int,int)
char m2 = max(c,d); // max(char,char)
int m3 = max(a,c); // ошибка: невозможно
// создать max(int,char)
}
template<class T>Программисту не нужно давать определение функции max(int,int), оно по умолчанию будет создано по шаблону.
T max(T a, T b) { return a>b?a:b; }
int max(int,int);
void f(int a, int b, char c, char d)
{
int m1 = max(a,b); // max(int,int)
char m2 = max(c,d); // max(char,char)
int m3 = max(a,c); // max(int,int)
}
Можно определить шаблон max так, чтобы сработал первоначальный вариант нашего примера:
template<class T1, class T2>Однако, в С и С++ правила для встроенных типов и операций над ними таковы, что использовать подобный шаблон с двумя параметрами может быть совсем непросто. Так, может оказаться неверно задавать тип результата функции как первый параметр (T1), или, по крайней мере, это может привести к неожиданному результату, например для вызова
T1 max(T1 a, T2 b) { return a>b?a:b; };
void f(int a, int b, char c, char d)
{
int m1 = max(a,b); // int max(int,int)
char m2 = max(c,d); // char max(char,char)
int m3 = max(a,c); // max(int,char)
}
max(c,i); // char max(char,int)Если в шаблоне для функции, которая может иметь множество параметров с различными арифметическими типами, используются два параметра, то в результате по шаблону будет порождаться слишком большое число определений разных функций. Более разумно добиваться преобразования типа, явно описав функцию с нужными типами.
8.6 Параметры шаблона типа
Параметр шаблона типа не обязательно должен быть именем типа (см. $$R.14.2). Помимо имен типов можно задавать строки, имена функций и выражения-константы. Иногда бывает нужно задать как параметр целое: template<class T, int sz> class buffer {
T v[sz]; // буфер объектов произвольного типа
// ...
};
void f()
{
buffer<char,128> buf1;
buffer<complex,20> buf2;
// ...
}Мы сделали sz параметром шаблона buffer, а не его объектов, и это означает, что размер буфера должен быть известен на стадии трансляции, чтобы его объекты было можно размещать, не используя свободную память. Благодаря этому свойству такие шаблоны как buffer полезны для реализации контейнерных классов, поскольку для последних первостепенным фактором, определяющим их эффективность, является возможность размещать их вне свободной памяти. Например, если в реализации класса string короткие строки размещаются в стеке, это дает существенный выигрыш для программы, поскольку в большинстве задач практически все строки очень короткие. Для реализации таких типов как раз и может пригодиться шаблон buffer. Каждый параметр шаблона типа для функции должен влиять на тип функции, и это влияние выражается в том, что он участвует по крайней мере в одном из типов формальных параметров функций, создаваемых по шаблону. Это нужно для того, чтобы функции можно было выбирать и создавать, основываясь только на их параметрах:
template<class T> void f1(T); // нормальноЗдесь все ошибки вызваны тем, что параметр-тип шаблона никак не влияет на формальные параметры функций.
template<class T> void f2(T*); // нормально
template<class T> T f3(int); // ошибка
template<int i> void f4(int[][i]); // ошибка
template<int i> void f5(int = i); // ошибка
template<class T, class C> void f6(T); // ошибка
template<class T> void f7(const T&, complex); // нормально
template<class T> void f8(Vector< List<T> >); // нормально
Подобного ограничения нет в шаблонах типа для классов. Дело в том, что параметр для такого шаблона нужно указывать всякий раз, когда описывается объект шаблонного класса. С другой стороны, для шаблонных классов возникает вопрос: когда два созданных по шаблону типа можно считать одинаковыми? Два имени шаблонного класса обозначают один и тот же класс, если совпадают имена их шаблонов, а используемые в этих именах параметры имеют одинаковые значения (с учетом возможных определений typedef, вычисления выражений-констант и т.д.). Вернемся к шаблону buffer:
template<class T, int sz>Если в шаблоне типа для класса используются параметры, задающие не типы, возможно появление конструкций, выглядящих двусмысленно:
class buffer {
T v[sz];
// ...
};
void f()
{
buffer<char,20> buf1;
buffer<complex,20> buf2;
buffer<char,20> buf3;
buffer<char,100> buf4;
buf1 = buf2; // ошибка: несоответствие типов
buf1 = buf3; // нормально
buf1 = buf4; // ошибка: несоответствие типов
// ...
}
template<int i>Этот пример синтаксически ошибочен, поскольку первая угловая скобка > завершает параметр шаблона. В маловероятном случае, когда вам понадобится параметр шаблона, являющийся выражением "больше чем", используйте скобки: X< (a>b)>.
class X { /* ... */ };
void f(int a, int b)
{
X < a > b>; // Как это понимать: X<a> b и потом
// недопустимая лексема, или X< (a>b) >; ?
}
8.7 Шаблоны типа и производные классы
Мы уже видели, что сочетание производных классов (наследование) и шаблонов типа может быть мощным средством. Шаблон типа выражает общность между всеми типами, которые используются как его параметры, а базовый класс выражает общность между всеми представлениями (объектами) и называется интерфейсом. Здесь возможны некоторые простые недоразумения, которых надо избегать.Два созданных по одному шаблону типа будут различны и между ними невозможно отношение наследования кроме единственного случая, когда у этих типов идентичны параметры шаблона. Например:
template<class T>Здесь v1 и v3 одного типа, а v2 имеет совершенно другой тип. Из того факта, что short неявно преобразуется в int, не следует, что есть неявное преобразование Vector<short> в Vector<int>:
class Vector { /* ... */ }
Vector<int> v1;
Vector<short> v2;
Vector<int> v3;
v2 = v3; // несоответствие типовНо этого и следовало ожидать, поскольку нет встроенного преобразования int[] в short[].
Аналогичный пример:
class circle: public shape { /* ... */ };
Vector<circle*> v4;
Vector<shape*> v5;
Vector<circle*> v6;Здесь v4 и v6 одного типа, а v5 имеет совершенно другой тип. Из того факта, что существует неявное преобразование circle в shape и circle* в shape*, не следует, что есть неявные преобразования Vector<circle*> в Vector<shape*> или Vector<circle*>* в Vector<shape*>* :v5 = v6; // несоответствие типовДело в том, что в общем случае структура (представление) класса, созданного по шаблону типа, такова, что для нее не предполагаются отношения наследования. Так, созданный по шаблону класс может содержать объект типа, заданного в шаблоне как параметр, а не просто указатель на него. Кроме того, допущение подобных преобразований приводит к нарушению контроля типов:
void f(Vector<circle>* pc)На примерах шаблонов Islist, Tlink, Slist, Splist, Islist_iter, Slist_iterи SortableVector мы видели, что шаблоны типа дают удобное средство для создания целых семейств классов. Без шаблонов создание таких семейств только с помощью производных классов может быть утомительным занятием, а значит, ведущим к ошибкам. С другой стороны, если отказаться от производных классов и использовать только шаблоны, то появляется множество копий функций-членов шаблонных классов, множество копий описательной части шаблонных классов и во множестве повторяются функции, использующие шаблоны типа.
{
Vector<shape>* ps = pc; // ошибка: несоответствие типов
(*ps)[2] = new square; // круглую ножку суем в квадратное
// отверстие (память выделена для
// square, а используется для circle
}
8.7.1 Задание реализации с помощью параметров шаблона
В контейнерных классах часто приходится выделять память. Иногда бывает необходимо (или просто удобно) дать пользователю возможность выбирать из нескольких вариантов выделения памяти, а также позволить ему задавать свой вариант. Это можно сделать несколькими способами. Один из способов состоит в том, что определяется шаблон типа для создания нового класса, в интерфейс которого входит описание соответствующего контейнера и класса, производящего выделение памяти по способу, описанному в $$6.7.2:template<class T, class A> class Controlled_containerШаблон типа здесь необходим, поскольку мы создаем контейнерный класс. Наследование от Container<T> нужно, чтобы класс Controlled_container можно было использовать как контейнерный класс. Шаблон типа с параметром A позволит нам использовать различные функции размещения:
: public Container<T>, private A {
// ...
void some_function()
{
// ...
T* p = new(A::operator new(sizeof(T))) T;
// ...
}
// ...
};
class Shared : public Arena { /* ... */ };
class Fast_allocator { /* ... */ };
Controlled_container<Process_descriptor,Shared> ptbl;
Controlled_container<Node,Fast_allocator> tree;
Controlled_container<Personell_record,Persistent> payroll;Это универсальный способ предоставлять производным классам содержательную информацию о реализации. Его положительными качествами являются систематичность и возможность использовать функции-подстановки. Для этого способа характерны необычно длинные имена. Впрочем, как обычно, typedef позволяет задать синонимы для слишком длинных имен типов:typedefОбычно шаблон типа для создания такого класса как pp_record используют только в том случае, когда добавляемая информация по реализации достаточно существенна, чтобы не вносить ее в производный класс ручным программированием. Примером такого шаблона может быть общий (возможно, для некоторых библиотек стандартный) шаблонный класс Comparator ($$8.4.2), а также нетривиальные (возможно, стандартные для некоторых библиотек) классы Allocator (классы для выделения памяти). Отметим, что построение производных классов в таких примерах идет по "основному проспекту", который определяет интерфейс с пользователем (в нашем примере это Container). Но есть и "боковые улицы", задающие детали реализации.
Controlled_container<Personell_record,Persistent> pp_record;
pp_record payroll;
8.8 Ассоциативный массив
Из всех универсальных невстроенных типов самым полезным, по всей видимости, является ассоциативный массив. Его часто называют таблицей (map), а иногда словарем, и он хранит пары значений. Имея одно из значений, называемое ключом, можно получить доступ к другому, называемому просто значением. Ассоциативный массив можно представлять как массив, в котором индекс не обязан быть целым: template<class K, class V> class Map {
// ...
public:
V& operator[](const K&); // найти V, соответствующее K
// и вернуть ссылку на него
// ...
};Здесь ключ типа K обозначает значение типа V. Предполагается, что ключи можно сравнивать с помощью операций == и <, так что массив можно хранить в упорядоченном виде. Отметим, что класс Mapотличается от типа assoc из $$7.8 тем, что для него нужна операция "меньше чем", а не функция хэширования.
Приведем простую программу подсчета слов, в которой используются шаблон Map и тип String:
#include <String.h>Мы используем тип String для того, чтобы не беспокоиться о выделении памяти и переполнении ее, о чем приходится помнить, используя тип char*. Итератор Mapiter нужен для выбора по порядку всех значений массива. Итерация в Mapiter задается как имитация работы с указателями. Если входной поток имеет вид
#include <iostream.h>
#include "Map.h"
int main()
{
Map<String,int> count;
String word;
while (cin >> word) count[word]++;
for (Mapiter<String,int> p = count.first(); p; p++)
cout << p.value() << '\t' << p.key() << '\n';
return 0;
}
It was new. It was singular. It was simple. It must succeed.
программа выдаст
4 ItКонечно, определить ассоциативный массив можно многими способами, а, имея определение Map и связанного с ним класса итератора, мы можем предложить много способов для их реализации. Здесь выбран тривиальный способ реализации. Используется линейный поиск, который не подходит для больших массивов. Естественно, рассчитанная на коммерческое применение реализация будет создаваться, исходя из требований быстрого поиска и компактности представления (см. упражнение 4 из $$8.9). Мы используем список с двойной связью Link:
1 must
1 new.
1 simple.
1 singular.
1 succeed.
3 was.
template<class K, class V> class Map;Каждый объект Link содержит пару (ключ, значение). Классы описаны в Link как друзья, и это гарантирует, что объекты Link можно создавать, работать с ними и уничтожать только с помощью соответствующих классов итератора и Map. Обратите внимание на предварительные описания шаблонных классов Map и Mapiter.
template<class K, class V> class Mapiter;
template<class K, class V> class Link {
friend class Map<K,V>;
friend class Mapiter<K,V>;
private:
const K key;
V value;
Link* pre;
Link* suc;
Link(const K& k, const V& v) : key(k), value(v) { }
~Link() { delete suc; } // рекурсивное удаление всех
// объектов в списке
};
Шаблон Map можно определить так:
template<class K, class V> class Map {
friend class Mapiter<K,V>;
Link<K,V>* head;
Link<K,V>* current;
V def_val;
K def_key;
int sz;
void find(const K&);
void init() { sz = 0; head = 0; current = 0; }
public:
Map() { init(); }
Map(const K& k, const V& d)
: def_key(k), def_val(d) { init(); }
~Map() { delete head; } // рекурсивное удаление
// всех объектов в списке
Map(const Map&);
Map& operator= (const Map&);
V& operator[] (const K&);
int size() const { return sz; }
void clear() { delete head; init(); }
void remove(const K& k);
// функции для итерации
Mapiter<K,V> element(const K& k)
{
(void) operator[](k); // сделать k текущим элементом
return Mapiter<K,V>(this,current);
}
Mapiter<K,V> first();
Mapiter<K,V> last();
};Элементы хранятся в упорядоченном списке с дойной связью. Для простоты ничего не делается для ускорения поиска (см. упражнение 4 из $$8.9). Ключевой здесь является функция operator[]():template<class K, class V>Операция индексации возвращает ссылку на значение, которое соответствует заданному как параметр ключу. Если такое значение не найдено, возвращается новый элемент со стандартным значением. Это позволяет использовать операцию индексации в левой части присваивания. Стандартные значения для ключей и значений устанавливаются конструкторами Map. В операции индексации определяется значение current, используемое итераторами.
V& Map<K,V>::operator[] (const K& k)
{
if (head == 0) {
current = head = new Link<K,V>(k,def_val);
current->pre = current->suc = 0;
return current->value;
}
Link<K,V>* p = head;
for (;;) {
if (p->key == k) { // найдено
current = p;
return current->value;
}
if (k < p->key) { // вставить перед p (в начало)
current = new Link<K,V>(k,def_val);
current->pre = p->pre;
current->suc = p;
if (p == head) // текущий элемент становится начальным
head = current;
else
p->pre->suc = current;
p->pre = current;
return current->value;
}
Link<K,V>* s = p->suc;
if (s == 0) { // вставить после p (в конец)
current = new Link<K,V>(k,def_val);
current->pre = p;
current->suc = 0;
p->suc = current;
return current->value;
}
p = s;
}
}
Реализация остальных функций-членов оставлена в качестве упражнения:
template<class K, class V>Теперь нам осталось только определить итерацию. В классе Map есть функции-члены first(), last() и element(const K&), которые возвращают итератор, установленный соответственно на первый, последний или задаваемый ключом-параметром элемент. Сделать это можно, поскольку элементы хранятся в упорядоченном по ключам виде.
void Map<K,V>::remove(const K& k)
{
// см. упражнение 2 из $$8.10
}
template<class K, class V>
Map<K,V>::Map(const Map<K,V>& m)
{
// копирование таблицы Map и всех ее элементов
}
template<class K, class V>
Map& Map<K,V>::operator=(const Map<K,V>& m)
{
// копирование таблицы Map и всех ее элементов
}
Итератор Mapiter для Map определяется так:
template<class K, class V> class Mapiter {
friend class Map<K,V>;
Map<K,V>* m;
Link<K,V>* p;
Mapiter(Map<K,V>* mm, Link<K,V>* pp)
{ m = mm; p = pp; }
public:
Mapiter() { m = 0; p = 0; }
Mapiter(Map<K,V>& mm);
operator void*() { return p; }
const K& key();
V& value();
Mapiter& operator--(); // префиксная
void operator--(int); // постфиксная
Mapiter& operator++(); // префиксная
void operator++(int); // постфиксная
};После позиционирования итератора функции key() и value() из Mapiter выдают ключ и значение того элемента, на который установлен итератор.template<class K, class V> const K& Mapiter<K,V>::key()По аналогии с указателями определены операции ++ и -- для продвижения по элементам Map вперед и назад:
{
if (p) return p->key; else return m->def_key;
}
template<class K, class V> V& Mapiter<K,V>::value()
{
if (p) return p->value; else return m->def_val;
}
Mapiter<K,V>& Mapiter<K,V>::operator--() //префиксный декрементПостфиксные операции определены так, что они не возвращают никакого значения. Дело в том, что затраты на создание и передачу нового объекта Mapiter на каждом шаге итерации значительны, а польза от него будет не велика.
{
if (p) p = p->pre;
return *this;
}
void Mapiter<K,V>::operator--(int) // постфиксный декремент
{
if (p) p = p->pre;
}
Mapiter<K,V>& Mapiter<K,V>::operator++() // префиксный инкремент
{
if (p) p = p->suc;
return *this;
}
void Mapiter<K,V>::operator++(int) // постфиксный инкремент
{
if (p) p = p->suc;
}
Объект Mapiter можно инициализировать так, чтобы он был установлен на начало Map:
template<class K, class V> Mapiter<K,V>::Mapiter(Map<K,V>& mm)Операция преобразования operator void*() возвращает нуль, если итератор не установлен на элемент Map, и ненулевое значение иначе. Значит можно проверять итератор iter, например, так:
{
m == &mm; p = m->head;
}
void f(Mapiter<const char*, Shape*>& iter)Аналогичный прием используется для контроля потоковых операций ввода-вывода в $$10.3.2.
{
// ...
if (iter) {
// установлен на элемент таблицы
}
else {
// не установлен на элемент таблицы
}
// ...
}
Если итератор не установлен на элемент таблицы, его функции key() и value() возвращают ссылки на стандартные объекты. Если после всех этих определений вы забыли их назначение, можно привести еще одну небольшую программу, использующую таблицу Map. Пусть входной поток является списком пар значений следующего вида:
hammer 2Нужно отсортировать список так, чтобы значения, соответствующие одному предмету, складывались, и напечатать получившийся список вместе с итоговым значением:
nail 100
saw 3
saw 4
hammer 7
nail 1000
nail 250
hammer 9Вначале напишем функцию, которая читает входные строки и заносит предметы с их количеством в таблицу. Ключом в этой таблице является первое слово строки:
nail 1350
saw 7
-------------------
total 1366
template<class K, class V>Теперь можно написать простую программу, вызывающую функцию
void readlines(Map<K,V>&key)
{
K word;
while (cin >> word) {
V val = 0;
if (cin >> val)
key[word] +=val;
else
return;
}
}
readlines() и печатающую получившуюся таблицу:
main()
{
Map<String,int> tbl("nil",0);
readlines(tbl);
int total = 0;
for (Mapiter<String,int> p(tbl); p; ++p) {
int val = p.value();
total +=val;
cout << p.key() << '\t' << val << '\n';
}
cout << "--------------------\n";
cout << "total\t" << total << '\n';
}
8.9 Упражнения
1. (*2) Определите семейство списков с двойной связью, которые будут двойниками списков с одной связью, определенных в $$8.3.2. (*3) Определите шаблон типа String, параметром которого является тип символа. Покажите как его можно использовать не только для обычных символов, но и для гипотетического класса lchar, который представляет символы не из английского алфавита или расширенный набор символов. Нужно постараться так определить String, чтобы пользователь не заметил ухудшения характеристик программы по памяти и времени или в удобстве по сравнению с обычным строковым классом.
3. (*1.5) Определите класс Record (запись) с двумя членами-данными:
count (количество) и price (цена). Упорядочите вектор из таких записей по каждому из членов. При этом нельзя изменять функцию сортировки и шаблон Vector.
4. (*2) Завершите определения шаблонного класса Map, написав недостающие функции-члены.
5. (*2) Задайте другую реализацию Map из $$8.8, используя списочный класс с двойной связью.
6. (*2.5) Задайте другую реализацию Map из $$8.8, используя сбалансированное дерево. Такие деревья описаны в $$6.2.3 книги Д. Кнут "Искусство программирования для ЭВМ" т.1, "Мир", 1978 [K].
7. (*2) Сравните качество двух реализаций Map. В первой используется класс Link со своей собственной функцией размещения, а во второй
- без нее.
8. (*3) Сравните производительность программы подсчета слов из $$8.8и такой же программы, не использующей класса Map. Операции ввода-вывода должны одинаково использоваться в обеих программах.
Сравните несколько таких программ, использующих разные варианты класса Map, в том числе и класс из вашей библиотеки, если он там есть.
9. (*2.5) С помощью класса Map реализуйте топологическую сортировку.
Она описана в [K] т.1, стр. 323-332. (см. упражнение 6).
10. (*2) Модифицируйте программу из $$8.8 так, чтобы она работала правильно для длинных имен и для имен, содержащих пробелы
(например, "thumb back").
11. (*2) Определите шаблон типа для чтения различных видов строк, например, таких (предмет, количество, цена).
12. (*2) Определите класс Sort из $$8.4.5, использующий сортировку по методу Шелла. Покажите как можно задать метод сортировки с помощью параметра шаблона. Алгоритм сортировки описан в [K]
т.3, $$5.2.1 (см. упражнение 6).
13. (*1) Измените определения Map и Mapiter так, чтобы постфиксные операции ++ и -- возвращали объект Mapiter.
14. (*1.5) Используйте шаблоны типа в стиле модульного программирования, как это было показано в $$8.4.5 и напишите функцию сортировки, рассчитанную сразу на Vector<T> и T[].
ГЛАВА 9. Механизм обработки особых ситуаций
Я прервал вас, поэтому не прерывайте меня.- Уинстон Черчилл
В этой главе описан механизм обработки особых ситуаций и некоторые, основывающиеся на нем, способы обработки ошибок. Механизм состоит в запуске особой ситуации, которую должен перехватить специальный обработчик. Описываются правила перехвата особых ситуаций и правила реакции на неперехваченные и неожиданные особые ситуации.
Целые группы особых ситуаций можно определить как производные классы. Описывается способ, использующий деструкторы и обработку особых ситуаций, который обеспечивает надежное и скрытое от пользователя управление ресурсами.
9.1 Обработка ошибок
Создатель библиотеки способен обнаружить динамические ошибки, но не представляет какой в общем случае должна быть реакция на них. Пользователь библиотеки способен написать реакцию на такие ошибки, но не в силах их обнаружить. Если бы он мог, то сам разобрался бы с ошибками в своей программе, и их не пришлось бы выявлять в библиотечных функциях. Для решения этой проблемы в язык введено понятие особой ситуации. Только недавно комитетом по стандартизации С++ особые ситуации были включены в стандарт языка, но на время написания этой книги они еще не вошли в большинство реализаций. Суть этого понятия в том, что функция, которая обнаружила ошибку и не может справиться с нею, запускает особую ситуацию, рассчитывая, что устранить проблему можно в той функции, которая прямо или опосредованно вызывала первую. Если функция рассчитана на обработку ошибок некоторого вида, она может указать это явно, как готовность перехватить данную особую ситуацию.Рассмотрим в качестве примера как для класса Vector можно представлять и обрабатывать особые ситуации, вызванные выходом за границу массива:
class Vector {
int* p;
int sz;
public:
class Range { }; // класс для особой ситуации
int& operator[](int i);
// ...
};Предполагается, что объекты класса Range будут использоваться как особые ситуации, и запускать их можно так:int& Vector::operator[](int i)Если в функции предусмотрена реакция на ошибку недопустимого значения индекса, то ту часть функции, в которой эти ошибки будут перехватываться, надо поместить в оператор try. В нем должен быть и обработчик особой ситуации:
{
if (0<=i && i<sz) return p[i];
throw Range();
}
void f(Vector& v)Обработчиком особой ситуации называется конструкция
{
// ...
try {
do_something(v); // содержательная часть, работающая с v
}
catch (Vector::Range) {
// обработчик особой ситуации Vector::Range
// если do_something() завершится неудачно,
// нужно как-то среагировать на это
// сюда мы попадем только в том случае, когда
// вызов do_something() приведет к вызову Vector::operator[]()
// из-за недопустимого значения индекса
}
// ...
}
catch ( /* ... */ ) {
// ...
}Ее можно использовать только сразу после блока, начинающегося служебным словом try, или сразу после другого обработчика особой ситуации. Служебным является и слово catch. После него идет в скобках описание, которое используется аналогично описанию формальных параметров функции, а именно, в нем задается тип объектов, на которые рассчитан обработчик, и, возможно, имена параметров (см. $$9.3). Если в do_something() или в любой вызванной из нее функции произойдет ошибка индекса (на любом объекте Vector), то обработчик перехватит особую ситуацию и будет выполняться часть, обрабатывающая ошибку. Например, определения следующих функций приведут к запуску обработчика в f():void do_something()Процесс запуска и перехвата особой ситуации предполагает просмотр цепочки вызовов от точки запуска особой ситуации до функции, в которой она перехватывается. При этом восстанавливается состояние стека, соответствующее функции, перехватившей ошибку, и при проходе по всей цепочке вызовов для локальных объектов функций из этой цепочки вызываются деструкторы. Подробно это описано в $$9.4.
{
// ...
crash(v);
// ...
}
void crash(Vector& v)
{
v[v.size()+10]; // искусственно вызываем ошибку индекса
}
Если при просмотре всей цепочки вызовов, начиная с запустившей особую ситуацию функции, не обнаружится подходящий обработчик, то программа завершается. Подробно это описано в $$9.7.
Если обработчик перехватил особую ситуацию, то она будет обрабатываться и другие, рассчитанные на эту ситуацию, обработчики не будут рассматриваться. Иными словами, активирован будет только тот обработчик, который находится в самой последней вызывавшейся функции, содержащей соответствующие обработчики. В нашем примере функция f() перехватит Vector::Range, поэтому эту особую ситуацию нельзя перехватить ни в какой вызывающей f() функции:
int ff(Vector& v)
{
try {
f(v); // в f() будет перехвачена Vector::Range
}
catch (Vector::Range) { // значит сюда мы никогда не попадем
// ...
}
}
9.1.1 Особые ситуации и традиционная обработка ошибок
Наш способ обработки ошибок по многим параметрам выгодно отличается от более традиционных способов. Перечислим, что может сделать операция индексации Vector::operator[]() при обнаружении недопустимого значения индекса:[1] завершить программу;
[2] возвратить значение, трактуемое как "ошибка";
[3] возвратить нормальное значение и оставить программу в неопределенном состоянии;
[4] вызвать функцию, заданную для реакции на такую ошибку.
Вариант [1] ("завершить программу") реализуется по умолчанию в том случае, когда особая ситуация не была перехвачена. Для большинства ошибок можно и нужно обеспечить лучшую реакцию.
Вариант [2] ("возвратить значение "ошибка"") можно реализовать не всегда, поскольку не всегда удается определить значение "ошибка". Так, в нашем примере любое целое является допустимым значением для результата операции индексации. Если можно выделить такое особое значение, то часто этот вариант все равно оказывается неудобным, поскольку проверять на это значение приходится при каждом вызове. Так можно легко удвоить размер программы. Поэтому для обнаружения всех ошибок этот вариант редко используется последовательно.
Вариант [3] ("оставить программу в неопределенном состоянии") имеет тот недостаток, что вызывавшая функция может не заметить ненормального состояния программы. Например, во многих функциях стандартной библиотеки С для сигнализации об ошибке устанавливается соответствующее значениеглобальной переменной errno. Однако, в программах пользователя обычно нет достаточно последовательного контроля errno, и в результате возникают наведенные ошибки, вызванные тем, что стандартные функции возвращают не то значение. Кроме того, если в программе есть параллельные вычисления, использование одной глобальной переменной для сигнализации о разных ошибках неизбежно приведет к катастрофе.
Обработка особых ситуаций не предназначалась для тех случаев, на которые рассчитан вариант [4] ( "вызвать функцию реакции на ошибку"). Отметим, однако, что если особые ситуации не предусмотрены, то вместо функции реакции на ошибку можно как раз использовать только один из трех перечисленных вариантов. Обсуждение функций реакций и особых ситуацией будет продолжено в $$9.4.3.
Механизм особых ситуаций успешно заменяет традиционные способы обработки ошибок в тех случаях, когда последние являются неполным, некрасивым или чреватым ошибками решением. Этот механизм позволяет явно отделить часть программы, в которой обрабатываются ошибки, от остальной ее части, тем самым программа становится более понятной и с ней проще работать различным сервисным программам. Свойственный этому механизму регулярный способ обработки ошибок упрощает взаимодействие между раздельно написанными частями программы.
В этом способе обработки ошибок есть для программирующих на С новый момент: стандартная реакция на ошибку (особенно на ошибку в библиотечной функции) состоит в завершении программы. Традиционной была реакция продолжать программу в надежде, что она как-то завершится сама. Поэтому способ, базирующийся на особых ситуациях, делает программу более "хрупкой" в том смысле, что требуется больше усилий и внимания для ее нормального выполнения. Но это все-таки лучше, чем получать неверные результаты на более поздней стадии развития программы (или получать их еще позже, когда программу сочтут завершенной и передадут ничего не подозревающему пользователю). Если завершение программы является неприемлемой реакцией, можно смоделировать традиционную реакцию с помощью перехвата всех особых ситуаций или всех особых ситуаций, принадлежащих специальному классу ($$9.3.2).
Механизм особых ситуаций можно рассматривать как динамический аналог механизма контроля типов и проверки неоднозначности на стадии трансляции. При таком подходе более важной становится стадия проектирования программы, и требуется большая поддержка процесса выполнения программы, чем для программ на С. Однако, в результате получится более предсказуемая программа, ее будет проще встроить в программную систему, она будет понятнее другим программистам и с ней проще будет работать различным сервисным программам. Можно сказать, что механизм особых ситуаций поддерживает, подобно другим средствам С++, "хороший" стиль программирования, который в таких языках, как С, можно применять только не в полном объеме и на неформальном уровне.
Все же надо сознавать, что обработка ошибок остается трудной задачей, и, хотя механизм особых ситуаций более строгий, чем традиционные способы, он все равно недостаточно структурирован по сравнению с конструкциями, допускающими только локальную передачу управления.
9.1.2 Другие точки зрения на особые ситуации
"Особая ситуация" - одно из тех понятий, которые имеют разный смысл для разных людей. В С++ механизм особых ситуаций предназначен для обработки ошибок. В частности, он предназначен для обработки ошибок в программах, состоящих из независимо создаваемых компонентов.Этот механизм рассчитан на особые ситуации, возникающие только при последовательном выполнении программы (например, контроль границ массива). Асинхронные особые ситуации такие, например, как прерывания от клавиатуры, нельзя непосредственно обрабатывать с помощью этого механизма. В различных системах существуют другие механизмы, например, сигналы, но они здесь не рассматриваются, поскольку зависят от конкретной системы.
Механизм особых ситуаций является конструкцией с нелокальной передачей управления и его можно рассматривать как вариант оператора return. Поэтому особые ситуации можно использовать для целей, никак не связанных с обработкой ошибок ($$9.5). Все-таки основным назначением механизма особых ситуаций и темой этой главы будет обработка ошибок и создание устойчивых к ошибкам программ.
9.2 Различение особых ситуаций
Естественно, в программе возможны несколько различных динамических ошибок. Эти ошибки можно сопоставить с особыми ситуациями, имеющими различные имена. Так, в классе Vector обычно приходится выявлять и сообщать об ошибках двух видов: ошибки диапазона и ошибки, вызванные неподходящим для конструктора параметром: class Vector {
int* p;
int sz;
public:
enum { max = 32000 };
class Range { }; // особая ситуация индекса
class Size { }; // особая ситуация "неверный размер"
Vector(int sz);
int& operator[](int i);
// ...
};Как было сказано, операция индексации запускает особую ситуацию Range, если ей задан выходящий из диапазона значений индекс. Конструктор запускает особую ситуацию Size, если ему задан недопустимый размер вектора:Vector::Vector(int sz)Пользователь класса Vector может различить эти две особые ситуации, если в проверяемом блоке (т.е. в блоке оператора try) укажет обработчики для обеих ситуаций:
{
if (sz<0 || max<sz) throw Size();
// ...
}
void f()В зависимости от особой ситуации будет выполняться соответствующий обработчик. Если управление дойдет до конца операторов обработчика, следующим будет выполняться оператор, который идет после списка обработчиков:
{
try {
use_vectors();
}
catch (Vector::Range) {
// ...
}
catch (Vector::Size) {
// ...
}
}
void f()Список обработчиков напоминает переключатель, но здесь в теле обработчика операторы break не нужны. Синтаксис списка обработчиков отличен от синтаксиса вариантов case переключателя частично по этой причине, частично потому, чтобы показать, что каждый обработчик определяет свою область видимости (см. $$9.8).
{
try {
use_vectors();
}
catch (Vector::Range) {
// исправить индекс и
// попробовать опять:
f();
}
catch (Vector::Size) {
cerr << "Ошибка в конструкторе Vector::Size";
exit(99);
}
// сюда мы попадем, если вообще не было особых ситуаций
// или после обработки особой ситуации Range
}
Не обязательно все особые ситуации перехватывать в одной функции:
void f1()Здесь f2() перехватит особую ситуацию Range, возникающую в use_vectors(), а особая ситуация Size будет оставлена для f1().
{
try {
f2(v);
}
catch (Vector::Size) {
// ...
}
}
void f2(Vector& v)
{
try {
use_vectors();
}
catch (Vector::Range) {
// ...
}
}
С точки зрения языка особая ситуация считается обработанной сразу при входе в тело ее обработчика. Поэтому все особые ситуации, запускаемые при выполнении этого обработчика, должны обрабатываться в функциях, вызвавших ту функцию, которая содержит проверяемый блок. Значит в следующем примере не возникнет бесконечного цикла:
try {
// ...
}
catch (input_overflow) {
// ...
throw input_overflow();
}Здесь input_overflow (переполнение при вводе) - имя глобального класса. Обработчики особых ситуаций могут быть вложенными:
try {
// ...
}
catch (xxii) {
try {
// сложная реакция
}
catch (xxii) {
// ошибка в процессе сложной реакции
}
}Однако, такая вложенность редко бывает нужна в обычных программах, и чаще всего она является свидетельством плохого стиля.9.3 Имена особых ситуаций
Особая ситуация перехватывается благодаря своему типу. Однако, запускается ведь не тип, а объект. Если нам нужно передать некоторую информацию из точки запуска в обработчик, то для этого ее следует поместить в запускаемый объект. Например, допустим нужно знать значение индекса, выходящее за границы диапазона: class Vector {
// ...
public:
class Range {
public:
int index;
Range(int i) : index(i) { }
};
// ...
int& operator[](int i)
// ...
};
int Vector::operator[](int i)
{
if (o<=i && i <sz) return p[i];
throw Range(i);
}Чтобы исследовать недопустимое значение индекса, в обработчике нужно дать имя объекту, представляющему особую ситуацию:void f(Vector& v)Конструкция в скобках после служебного слова catch является по сути описанием и она аналогична описанию формального параметра функции. В ней указывается каким может быть тип параметра (т.е. особой ситуации) и может задаваться имя для фактической, т.е. запущенной, особой ситуации. Вспомним, что в шаблонах типов у нас был выбор для именования особых ситуаций. В каждом созданном по шаблону классе был свой класс особой ситуации:
{
// ...
try {
do_something(v);
}
catch (Vector::Range r ) {
cerr << "недопустимый индекс" << r.index << '\n';
// ...
}
// ...
}
template<class T> class Allocator {
// ...
class Exhausted { }
// ...
T* get();
};
void f(Allocator<int>& ai, Allocator<double>& ad)
{
try {
// ...
}
catch (Allocator<int>::Exhausted) {
// ...
}
catch (Allocator<double>::Exhausted) {
// ...
}
}С другой стороны, особая ситуация может быть общей для всех созданных по шаблону классов: class Allocator_Exhausted { };
template<class T> class Allocator {
// ...
T* get();
};
void f(Allocator<int>& ai, Allocator<double>& ad)
{
try {
// ...
}
catch (Allocator_Exhausted) {
// ...
}
}Какой способ задания особой ситуации предпочтительней, сказать трудно. Выбор зависит от назначения рассматриваемого шаблона.9.3.1 Группирование особых ситуаций
Особые ситуации естественным образом разбиваются на семейства. Действительно, логично представлять семейство Matherr, в которое входят Overflow (переполнение), Underflow (потеря значимости) и некоторые другие особые ситуации. Семейство Matherr образуют особые ситуации, которые могут запускать математические функции стандартной библиотеки.Один из способов задания такого семейства сводится к определению Matherr как типа, возможные значения которого включают Overflow и все остальные:
enum { Overflow, Underflow, Zerodivide, /* ... */ };
try {
// ...
}
catch (Matherr m) {
switch (m) {
case Overflow:
// ...
case Underflow:
// ...
// ...
}
// ...
}Другой способ предполагает использование наследования и виртуальных функций, чтобы не вводить переключателя по значению поля типа. Наследование помогает описать семейства особых ситуаций: class Matherr { };
class Overflow: public Matherr { };
class Underflow: public Matherr { };
class Zerodivide: public Matherr { };
// ...Часто бывает так, что нужно обработать особую ситуацию Matherr не зависимо от того, какая именно ситуация из этого семейства произошла. Наследование позволяет сделать это просто: try {
// ...
}
catch (Overflow) {
// обработка Overflow или любой производной ситуации
}
catch (Matherr) {
// обработка любой отличной от Overflow ситуации
}В этом примере Overflow разбирается отдельно, а все другие особые ситуации из Matherr разбираются как один общий случай. Конечно, функция, содержащая catch (Matherr), не будет знать какую именно особую ситуацию она перехватывает. Но какой бы она ни была, при входе в обработчик передаваемая ее копия будет Matherr. Обычно это как раз то, что нужно. Если это не так, особую ситуацию можно перехватить по ссылке (см. $$9.3.2). Иерархическое упорядочивание особых ситуаций может играть важную роль для создания ясной структуры программы. Действительно, пусть такое упорядочивание отсутствует, и нужно обработать все особые ситуации стандартной библиотеки математических функций. Для этого придется до бесконечности перечислять все возможные особые ситуации:
try {
// ...
}
catch (Overflow) { /* ... */ }
catch (Underflow) { /* ... */ }
catch (Zerodivide) { /* ... */ }
// ...Это не только утомительно, но и опасно, поскольку можно забыть какую-нибудь особую ситуацию. Кроме того, необходимость перечислить в проверяемом блоке все особые ситуации практически гарантирует, что, когда семейство особых ситуаций библиотеки расширится, в программе пользователя возникнет ошибка. Это значит, что при введении новой особой ситуации в библиотеки математических функций придется перетранслировать все части программы, которые содержат обработчики всех особых ситуаций из Matherr. В общем случае такая перетрансляция неприемлема. Часто даже нет возможности найти все требующие перетрансляции части программы. Если такая возможность есть, нельзя требовать, чтобы всегда был доступен исходной текст любой части большой программы, или чтобы у нас были права изменять любую часть большой программы, исходный текст которой мы имеем. На самом деле, пользователь не должен думать о внутреннем устройстве библиотек. Все эти проблемы перетрансляции и сопровождения могут привести к тому, что после создания первой версии библиотеки будет нельзя вводить в ней новые особые ситуации. Но такое решение не подходит практически для всех библиотек. Все эти доводы говорят за то, что особые ситуации нужно определять как иерархию классов (см. также $$9.6.1). Это, в свою очередь, означает, что особые ситуации могут быть членами нескольких групп:
class network_file_err // ошибки файловой системы в сетиОсобую ситуацию network_file_err можно перехватить в функциях, обрабатывающих особые ситуации сети:
: public network_err, // ошибки сети
public file_system_err { // ошибки файловой системы
// ...
};
void f()Ее также можно перехватить в функциях, обрабатывающих особые ситуации файловой системы:
{
try {
// какие-то операторы
}
catch (network_err) {
// ...
}
}
void g()Это важный момент, поскольку такой системный сервис как работа в сети должен быть прозрачен, а это означает, что создатель функции g() может даже и не знать, что эта функция будет выполняться в сетевом режиме.
{
try {
// какие-то другие операторы
}
catch (file_system_err) {
// ...
}
}
Отметим, что в настоящее время нет стандартного множества особых ситуаций для стандартной математической библиотеки и библиотеки ввода-вывода. Задача комитетов ANSI и ISO по стандартизации С++ решить нужно ли такое множество и какие в нем следует использовать имена и классы.
Поскольку можно сразу перехватить все особые ситуации (см. $$9.3.2), нет настоятельной необходимости создавать для этой цели общий, базовый для всех особых ситуаций, класс. Однако, если все особые ситуации являются производными от пустого класса Exception (особая ситуация), то в интерфейсах их использование становится более регулярным (см. $$9.6). Если вы используете общий базовый класс Exception, убедитесь, что в нем ничего нет кроме виртуального деструктора. В противном случае такой класс может вступить в противоречие с предполагаемым стандартом.
9.3.2 Производные особые ситуации
Если для обработки особых ситуаций мы используем иерархию классов, то, естественно, каждый обработчик должен разбираться только с частью информации, передаваемой при особых ситуациях. Можно сказать, что, как правило, особая ситуация перехватывается обработчиком ее базового класса, а не обработчиком класса, соответствующего именно этой особой ситуации. Именование и перехват обработчиком особой ситуации семантически эквивалентно именованию и получению параметра в функции. Проще говоря, формальный параметр инициализируется значением фактического параметра. Это означает, что запущенная особая ситуация "низводится" до особой ситуации, ожидаемой обработчиком. Например: class Matherr {
// ...
virtual void debug_print();
};
class Int_overflow : public Matherr {
public:
char* op;
int opr1, opr2;;
int_overflow(const char* p, int a, int b)
{ cerr << op << '(' << opr1 << ',' << opr2 << ')'; }
};
void f()
{
try {
g();
}
catch (Matherr m) {
// ...
}
}При входе в обработчик Matherr особая ситуация m является объектом Matherr, даже если при обращении к g() была запущена Int_overflow. Это означает, что дополнительная информация, передаваемая вInt_overflow, недоступна.
Как обычно, чтобы иметь доступ к дополнительной информации можно использовать указатели или ссылки. Поэтому можно было написать так:
int add(int x, int y) // сложить x и y с контролемЗдесь последнее обращение к add приведет к запуску особой ситуации, который, в свою очередь, приведет к вызову Int_overflow::debug_print(). Если бы особая ситуация передавалась по значению, а не по ссылке, то была бы вызвана функция Matherr::debug_print().
{
if (x > 0 && y > 0 && x > MAXINT - y
|| x < 0 && y < 0 && x < MININT + y)
throw Int_overflow("+", x, y);
// Сюда мы попадаем, либо когда проверка
// на переполнение дала отрицательный результат,
// либо когда x и y имеют разные знаки
return x + y;
}
void f()
{
try {
add(1,2);
add(MAXINT,-2);
add(MAXINT,2); // а дальше - переполнение
}
catch (Matherr& m) {
// ...
m.debug_print();
}
}
Нередко бывает так, что перехватив особую ситуацию, обработчик решает, что с этой ошибкой он ничего не сможет поделать. В таком случае самое естественное запустить особую ситуациюснова в надежде, что с ней сумеет разобраться другой обработчик:
void h()Повторный запуск записывается как оператор throw без параметров. При этом снова запускается исходная особая ситуация, которая была перехвачена, а не та ее часть, на которую рассчитан обработчик
{
try {
// какие-то операторы
}
catch (Matherr) {
if (can_handle_it) { // если обработка возможна,
// сделать ее
}
else {
throw; // повторный запуск перехваченной
// особой ситуации
}
}
}
Matherr. Иными словами, если была запущена Int_overflow, вызывающая h() функция могла бы перехватить ее как Int_overflow, несмотря на то, что она была перехвачена в h() как Matherr и запущена снова:
void k()Полезен вырожденный случай перезапуска. Как и для функций, эллипсис ... для обработчика означает "любой параметр", поэтому оператор catch (...) означает перехват любой особой ситуации:
{
try {
h();
// ...
}
catch (Int_overflow) {
// ...
}
}
void m()Этот пример надо понимать так: если при выполнении основной части m() возникает особая ситуация, выполняется обработчик, которые выполняет общие действия по устранению последствий особой ситуации, после этих действий особая ситуация, вызвавшая их, запускается повторно.
{
try {
// какие-то операторы
}
catch (...) {
// привести все в порядок
throw;
}
}
Поскольку обработчик может перехватить производные особые ситуации нескольких типов, порядок, в котором идут обработчики в проверяемом блоке, существенен. Обработчики пытаются перехватить особую ситуацию в порядке их описания. Приведем пример:
try {
// ...
}
catch (ibuf) {
// обработка переполнения буфера ввода
}
catch (io) {
// обработка любой ошибки ввода-вывода
}
catch (stdlib) {
// обработка любой особой ситуации в библиотеке
}
catch (...) {
// обработка всех остальных особых ситуаций
}Тип особой ситуации в обработчике соответствует типу запущенной особой ситуации в следующих случаях: если эти типы совпадают, или второй тип является типом доступного базового класса запущенной ситуации, или он является указателем на такой класс, а тип ожидаемой ситуации тоже указатель ($$R.4.6). Поскольку транслятору известна иерархия классов, он способен обнаружить такие нелепые ошибки, когда обработчик catch (...) указан не последним, или когда обработчик ситуации базового класса предшествует обработчику производной от этого класса ситуации ($$R15.4). В обоих случая, последующий обработчик (или обработчики) не могут быть запущены, поскольку они "маскируются" первым обработчиком.
9.4 Запросы ресурсов
Если в некоторой функции потребуются определенные ресурсы, например, нужно открыть файл, отвести блок памяти в области свободной памяти, установить монопольные права доступа и т.д., для дальнейшей работы системы обычно бывает крайне важно, чтобы ресурсы были освобождены надлежащим образом. Обычно такой "надлежащий способ" реализует функция, в которой происходит запрос ресурсов и освобождение их перед выходом. Например:void use_file(const char* fn)Все это выглядит вполне нормально до тех пор, пока вы не поймете, что при любой ошибке, происшедшей после вызова fopen() и до вызова fclose(), возникнет особая ситуация, в результате которой мы выйдем из use_file(), не обращаясь к fclose(). Стоит сказать, что та же проблема возникает и в языках, не поддерживающих особые ситуации. Так, обращение к функции longjump() из стандартной библиотеки С может иметь такие же неприятные последствия. Если вы создаете устойчивую к ошибкам системам, эту проблему придется решать. Можно дать примитивное решение:
{
FILE* f = fopen(fn,"w");
// работаем с f
fclose(f);
}
void use_file(const char* fn)Вся часть функции, работающая с файлом f, помещена в проверяемый блок, в котором перехватываются все особые ситуации, закрывается файл и особая ситуация запускается повторно.
{
FILE* f = fopen(fn,"w");
try {
// работаем с f
}
catch (...) {
fclose(f);
throw;
}
fclose(f);
}
Недостаток этого решения в его многословности, громоздкости и потенциальной расточительности. К тому же всякое многословное и громоздкое решение чревато ошибками, хотя бы в силу усталости программиста. К счастью, есть более приемлемое решение. В общем виде проблему можно сформулировать так:
void acquire()Как правило бывает важно, чтобы ресурсы освобождались в обратном по сравнению с запросами порядке. Это очень сильно напоминает порядок работы с локальными объектами, создаваемыми конструкторами и уничтожаемыми деструкторами. Поэтому мы можем решить проблему запроса и освобождения ресурсов, если будем использовать подходящие объекты классов с конструкторами и деструкторами. Например, можно определить класс FilePtr, который выступает как тип FILE* :
{
// запрос ресурса 1
// ...
// запрос ресурса n
// использование ресурсов
// освобождение ресурса n
// ...
// освобождение ресурса 1
}
class FilePtr {
FILE* p;
public:
FilePtr(const char* n, const char* a)
{ p = fopen(n,a); }
FilePtr(FILE* pp) { p = pp; }
~FilePtr() { fclose(p); }
operator FILE*() { return p; }
};Построить объект FilePtr можно либо, имея объект типа FILE*, либо, получив нужные для fopen() параметры. В любом случае этот объект будет уничтожен при выходе из его области видимости, и его деструктор закроет файл. Теперь наш пример сжимается до такой функции:void use_file(const char* fn)Деструктор будет вызываться независимо от того, закончилась ли функция нормально, или произошел запуск особой ситуации.
{
FilePtr f(fn,"w");
// работаем с f
}
9.4.1 Конструкторы и деструкторы
Описанный способ управления ресурсами обычно называют "запрос ресурсов путем инициализации". Это универсальный прием, рассчитанный на свойства конструкторов и деструкторов и их взаимодействие с механизмом особых ситуаций.Объект не считается построенным, пока не завершил выполнение его конструктор. Только после этого возможна раскрутка стека, сопровождающая вызов деструктора объекта. Объект, состоящий из вложенных объектов, построен в той степени, в какой построены вложенные объекты.
Хорошо написанный конструктор должен гарантировать, что объект построен полностью и правильно. Если ему не удается сделать это, он должен, насколько это возможно, восстановить состояние системы, которое было до начала построения. Для простых конструкторов было бы идеально всегда удовлетворять хотя бы одному условию - правильности или законченности объектов, и никогда не оставлять объект в "наполовину построенном" состоянии. Этого можно добиться, если применять при построении членов способ "запроса ресурсов путем инициализации".
Рассмотрим класс X, конструктору которого требуется два ресурса: файл x и замок y (т.е. монопольные права доступа к чему-либо). Эти запросы могут быть отклонены и привести к запуску особой ситуации. Чтобы не усложнять работу программиста, можно потребовать, чтобы конструктор класса X никогда не завершался тем, что запрос на файл удовлетворен, а на замок нет. Для представления двух видов ресурсов мы будем использовать объекты двух классов FilePtr и LockPtr (естественно, было бы достаточно одного класса, если x и y ресурсы одного вида). Запрос ресурса выглядит как инициализация представляющего ресурс объекта:
class X {
FilePtr aa;
LockPtr bb;
// ...
X(const char* x, const char* y)
: aa(x), // запрос `x'
bb(y) // запрос `y'
{ }
// ...
};Теперь, как это было для случая локальных объектов, всю служебную работу, связанную с ресурсами, можно возложить на реализацию. Пользователь не обязан следить за ходом такой работой. Например, если после построения aa и до построения bb возникнет особая ситуация, то будет вызван только деструктор aa, но не bb. Это означает, что если строго придерживаться этой простой схемы запроса ресурсов, то все будет в порядке. Еще более важно то, что создателю конструктора не нужно самому писать обработчики особых ситуаций.Для требований выделить блок в свободной памяти характерен самый произвольный порядок запроса ресурсов. Примеры таких запросов уже неоднократно встречались в этой книге:
class X {
int* p;
// ...
public:
X(int s) { p = new int[s]; init(); }
~X() { delete[] p; }
// ...
};Это типичный пример использования свободной памяти, но в совокупности с особыми ситуациями он может привести к ее исчерпанию памяти. Действительно, если в init() запущена особая ситуация, то отведенная память не будет освобождена. Деструктор не будет вызываться, поскольку построение объекта не было завершено. Есть более надежный вариант этого примера: template<class T> class MemPtr {
public:
T* p;
MemPtr(size_t s) { p = new T[s]; }
~MemPtr() { delete[] p; }
operator T*() { return p; }
}
class X {
MemPtr<int> cp;
// ...
public:
X(int s):cp(s) { init(); }
// ...
};Теперь уничтожение массива, на который указывает p, происходит неявно в MemPtr. Если init() запустит особую ситуацию, отведенная память будет освобождена при неявном вызове деструктора для полностью построенного вложенного объекта cp. Отметим также, что стандартная стратегия выделения памяти в С++ гарантирует, что если функции operator new() не удалось выделить память для объекта, то конструктор для него никогда не будет вызываться. Это означает, что пользователю не надо опасаться, что конструктор или деструктор может быть вызван для несуществующего объекта.
Теоретически дополнительные расходы, требующиеся для обработки особых ситуаций, когда на самом деле ни одна из них не возникла, могут быть сведены к нулю. Однако, вряд ли это верно для ранних реализациях языка. Поэтому будет разумно в критичных внутренних циклах программы пока не использовать локальные переменные классов с деструкторами.
9.4.2 Предостережения
Не все программы должны быть устойчивы ко всем видам ошибок. Не все ресурсы являются настолько критичными, чтобы оправдать попытки защитить их с помощью описанного способа "запроса ресурсов путем инициализации". Есть множество программ, которые просто читают входные данные и выполняются до конца. Для них самой подходящей реакцией на динамическую ошибку будет просто прекращение счета(после выдачи соответствующего сообщения). Освобождение всех затребованных ресурсов возлагается на систему, а пользователь должен произвести повторный запуск программы с более подходящими входными данными. Наша схема предназначена для задач, в которых такая примитивная реакция на динамическую ошибку неприемлема. Например, разработчик библиотеки обычно не в праве делать допущения о том, насколько устойчива к ошибкам, должна быть программа, работающая с библиотекой. Поэтому он должен учитывать все динамические ошибки и освобождать все ресурсы до возврата из библиотечной функции в пользовательскую программу. Метод "запроса ресурсов путем инициализации" в совокупности с особыми ситуациями, сигнализирующими об ошибке, может пригодиться при создании многих библиотек.
9.4.3 Исчерпание ресурса
Есть одна из вечных проблем программирования: что делать, если не удалось удовлетворить запрос на ресурс? Например, в предыдущем примере мы спокойно открывали с помощью fopen() файлы и запрашивали с помощью операции new блок свободной памяти, не задумываясь при этом, что такого файла может не быть, а свободная память может исчерпаться. Для решения такого рода проблем у программистов есть два способа: Повторный запрос: пользователь должен изменить свой запрос и повторить его.Завершение: запросить дополнительные ресурсы от системы, если их нет, запустить особую ситуацию. Первый способ предполагает для задания приемлемого запроса содействие пользователя, во втором пользователь должен быть готов правильно отреагировать на отказ в выделении ресурсов. В большинстве случаев последний способ намного проще и позволяет поддерживать в системе разделение различных уровней абстракции.
В С++ первый способ поддержан механизмом вызова функций, а второй - механизмом особых ситуаций. Оба способа можно продемонстрировать на примере реализации и использования операции
new:
#include <stdlib.h>Если операция new() не может найти свободной памяти, она обращается к управляющей функции _new_handler(). Если в _new_handler() можно выделить достаточный объем памяти, все нормально. Если нет, из управляющей функции нельзя возвратиться в операцию new, т.к. возникнет бесконечный цикл. Поэтому управляющая функция может запустить особую ситуацию и предоставить исправлять положение программе, обратившейся к new:
extern void* _last_allocation;
extern void* operator new(size_t size)
{
void* p;
while ( (p=malloc(size))==0 ) {
if (_new_handler)
(*_new_handler)(); // обратимся за помощью
else
return 0;
}
return _last_allocation=p;
}
void my_new_handler()Где-то в программе должен быть проверяемый блок с соответствующим обработчиком:
{
try_find_some_memory(); // попытаемся найти
// свободную память
if (found_some()) return; // если она найдена, все в порядке
throw Memory_exhausted(); // иначе запускаем особую
// ситуацию "Исчерпание_памяти"
}
try {
// ...
}
catch (Memory_exhausted) {
// ...
}В функции operator new() использовался указатель на управляющую функцию _new_handler, который настраивается стандартной функцией set_new_handler(). Если нужно настроиться на собственную управляющую функцию, надо обратиться такset_new_handler(&my_new_handler);Перехватить ситуацию Memory_exhausted можно следующим образом:
void (*oldnh)() = set_new_handler(&my_new_handler);Можно поступить еще лучше, если к управляющей функции применить описанный в $$9.4 метод "запроса ресурсов путем инициализации" и убрать обработчик catch (...).
try {
// ...
}
catch (Memory_exhausted) {
// ...
}
catch (...) {
set_new_handler(oldnh); // восстановить указатель на
// управляющую функцию
throw(); // повторный запуск особой ситуации
}
set_new_handler(oldnh); // восстановить указатель на
// управляющую функцию
В решении, использующим my_new_handler(), от точки обнаружения ошибки до функции, в которой она обрабатывается, не передается никакой информации. Если нужно передать какие-то данные, то пользователь может включить свою управляющую функцию в класс. Тогда в функции, обнаружившей ошибку, нужные данные можно поместить в объект этого класса. Подобный способ, использующий объекты-функции, применялся в $$10.4.2 для реализации манипуляторов. Способ, в котором используется указатель на функцию или объект-функция для того, чтобы из управляющей функции, обслуживающей некоторый ресурс, произвести "обратный вызов" функции запросившей этот ресурс, обычно называется просто обратным вызовом (callback).
При этом нужно понимать, что чем больше информации передается из обнаружившей ошибку функции в функцию, пытающуюся ее исправить, тем больше зависимость между этими двумя функциями. В общем случае лучше сводить к минимуму такие зависимости, поскольку всякое изменение в одной из функций придется делать с учетом другой функцией, а, возможно, ее тоже придется изменять. Вообще, лучше не смешивать отдельные компоненты программы. Механизм особых ситуаций позволяет сохранять раздельность компонентов лучше, чем обычный механизм вызова управляющих функций, которые задает функция, затребовавшая ресурс.
В общем случае разумный подход состоит в том, чтобы выделение ресурсов было многоуровневым (в соответствии с уровнями абстракции). При этом нужно избегать того, чтобы функции одного уровня зависели от управляющей функции, вызываемой на другом уровне. Опыт создания больших программных систем показывает, что со временем удачные системы развиваются именно в этом направлении.
9.4.4 Особые ситуации и конструкторы
Особые ситуации дают средство сигнализировать о происходящих в конструкторе ошибках. Поскольку конструктор не возвращает такое значение, которое могла бы проверить вызывающая функция, есть следующие обычные (т.е. не использующие особые ситуации) способы сигнализации:
[1] Возвратить объект в ненормальном состоянии в расчете, что пользователь проверит его состояние.
[2] Установить значение нелокальной переменной, которое сигнализирует, что создать объект не удалось.
Особые ситуации позволяют тот факт, что создать объект не удалось, передать из конструктора вовне:
Vector::Vector(int size)В функции, создающей вектора, можно перехватить ошибки, вызванные недопустимым размером (Size()) и попытаться на них отреагировать:
{
if (sz<0 || max<sz) throw Size();
// ...
}
Vector* f(int i)Управляющая созданием вектора функция способна правильно отреагировать на ошибку. В самом обработчике особой ситуации можно применить какой-нибудь из стандартных способов диагностики и восстановления после ошибки. При каждом перехвате особой ситуации в управляющей функции может быть свой взгляд на причину ошибки. Если с каждой особой ситуацией передаются описывающие ее данные, то объем данных, которые нужно анализировать для каждой ошибки, растет. Основная задача обработки ошибок в том, чтобы обеспечить надежный и удобный способ передачи данных от исходной точки обнаружения ошибки до того места, где после нее возможно осмысленное восстановление.
{
Vector* p;
try {
p = new Vector v(i);
}
catch (Vector::Size) {
// реакция на недопустимый размер вектора
}
// ...
return p;
}
Способ "запроса ресурсов путем инициализации" - самый надежное и красивое решение в том случае, когда имеются конструкторы, требующие более одного ресурса. По сути он позволяет свести задачу выделения нескольких ресурсов к повторно применяемому, более простому, способу, рассчитанному на один ресурс.
9.5 Особые ситуации могут не быть ошибками
Если особая ситуация ожидалась, была перехвачена и не оказала плохого воздействия на ход программы, то стоит ли ее называть ошибкой? Так говорят только потому, что программист думает о ней как об ошибке, а механизм особых ситуаций является средством обработки ошибок. С другой стороны, особые ситуации можно рассматривать просто как еще одну структуру управления. Подтвердим это примером: class message { /* ... */ }; // сообщение
class queue { // очередь
// ...
message* get(); // вернуть 0, если очередь пуста
// ...
};
void f1(queue& q)
{
message* m = q.get();
if (m == 0) { // очередь пуста
// ...
}
// используем m
}Этот пример можно записать так: class Empty { } // тип особой ситуации "Пустая_очередь"
class queue {
// ...
message* get(); // запустить Empty, если очередь пуста
// ...
};
void f2(queue& q)
{
try {
message* m = q.get();
// используем m
}
catch (Empty) { // очередь пуста
// ...
}
}В варианте с особой ситуацией есть даже какая-то прелесть. Это хороший пример того, когда трудно сказать, можно ли считать такую ситуацию ошибкой. Если очередь не должна быть пустой (т.е. она бывает пустой очень редко, скажем один раз из тысячи), и действия в случае пустой очереди можно рассматривать как восстановление, то в функции f2() взгляд на особую ситуацию будет такой, которого мы до сих пор и придерживались (т.е. обработка особых ситуаций есть обработка ошибок). Если очередь часто бывает пустой, а принимаемые в этом случае действия образуют одну из ветвей нормального хода программы, то придется отказаться от такого взгляда на особую ситуацию, а функцию f2() надо переписать: class queue {
// ...
message* get(); // запустить Empty, если очередь пуста
int empty();
// ...
};
void f3(queue& q)
{
if (q.empty()) { // очередь пуста
// ...
}
else {
message* m = q.get();
// используем m
}
}Отметим, что вынести из функции get() проверку очереди на пустоту можно только при условии, что к очереди нет параллельных обращений. Не так то просто отказаться от взгляда, что обработка особой ситуации есть обработка ошибки. Пока мы придерживаемся такой точки зрения, программа четко подразделяется на две части: обычная часть и часть обработки ошибок. Такая программа более понятна. К сожалению, в реальных задачах провести четкое разделение невозможно, поэтому структура программы должна (и будет) отражать этот факт. Допустим, очередь бывает пустой только один раз (так может быть, если функция get() используется в цикле, и пустота очереди говорит о конце цикла). Тогда пустота очереди не является чем-то странным или ошибочным. Поэтому, используя для обозначения конца очереди особую ситуацию, мы расширяем представление об особых ситуациях как ошибках. С другой стороны, действия, принимаемые в случае пустой очереди, явно отличаются от действий, принимаемых в ходе цикла (т.е. в обычном случае).
Механизм особых ситуаций является менее структурированным, чем такие локальные структуры управления как операторы if или for. Обычно он к тому же является не столь эффективным, если особая ситуация действительно возникла. Поэтому особые ситуации следует использовать только в том случае, когда нет хорошего решения с более традиционными управляющими структурами, или оно, вообще, невозможно. Например, в случае пустой очереди можно прекрасно использовать для сигнализации об этом значение, а именно нулевое значение указателя на строку message, значит особая ситуация здесь не нужна. Однако, если бы из класса queue мы получали вместо указателя значение типа int, то то могло не найтись такого значения, обозначающего пустую очередь. В таком случае функция get() становится эквивалентной операции индексации из $$9.1, и более привлекательно представлять пустую очередь с помощью особой ситуации. Последнее соображение подсказывает, что в самом общем шаблоне типа для очереди придется для обозначения пустой очереди использовать особую ситуацию, а работающая с очередью функция будет такой:
void f(Queue<X>& q)Если приведенный цикл выполняется тысячи раз, то он, по всей видимости, будет более эффективным, чем обычный цикл с проверкой условия пустоты очереди. Если же он выполняется только несколько раз, то обычный цикл почти наверняка эффективней.
{
try {
for (;;) { // ``бесконечный цикл''
// прерываемый особой ситуацией
X m = q.get();
// ...
}
}
catch (Queue<X>::Empty) {
return;
}
}
В очереди общего вида особая ситуация используется как способ возврата из функции get(). Использование особых ситуаций как способа возврата может быть элегантным способом завершения функций поиска. Особенно это подходит для рекурсивных функций поиска в дереве. Однако, применяя особые ситуации для таких целей, легко перейти грань разумного и получить маловразумительную программу. Все-таки всюду, где это действительно оправдано, надо придерживаться той точки зрения, что обработка особой ситуации есть обработка ошибки. Обработка ошибок по самой своей природе занятие сложное, поэтому ценность имеют любые методы, которые дают ясное представление ошибок в языке и способ их обработки.
9.6 Задание интерфейса
Запуск или перехват особой ситуации отражается на взаимоотношениях функций. Поэтому имеет смысл задавать в описании функции множество особых ситуаций, которые она может запустить:void f(int a) throw (x2, x3, x4);В этом описании указано, что f() может запустить особые ситуации x2, x3 и x4, а также ситуации всех производных от них типов, но больше никакие ситуации она не запускает. Если функция перечисляет свои особые ситуации, то она дает определенную гарантию всякой вызывающей ее функции, а именно, если попытается запустить иную особую ситуацию, то это приведет к вызову функции unexpected(). Стандартное предназначение unexpected() состоит в вызове функции terminate(), которая, в свою очередь, обычно вызывает abort(). Подробности даны в $$9.7.
По сути определение
void f() throw (x2, x3, x4)эквивалентно такому определению
{
// какие-то операторы
}
void f()Преимущество явного задания особых ситуаций функции в ее описании перед эквивалентным способом, когда происходит проверка на особые ситуации в теле функции, не только в более краткой записи. Главное здесь в том, что описание функции входит в ее интерфейс, который видим для всех вызывающих функций. С другой стороны, определение функции может и не быть универсально доступным. Даже если у вас есть исходные тексты всех библиотечных функций, обычно желание изучать их возникает не часто.
{
try {
// какие-то операторы
}
catch (x2) { // повторный запуск
throw;
}
catch (x3) { // повторный запуск
throw;
}
catch (x4) { // повторный запуск
throw;
}
catch (...) {
unexpected();
}
}
Если в описании функции не указаны ее особые ситуации, считается, что она может запустить любую особую ситуацию.
int f(); // может запустить любую особую ситуациюЕсли функция не будет запускать никаких особых ситуаций, ее можно описать, явно указав пустой список:
int g() throw (); // не запускает никаких особых ситуацийКазалось было бы логично, чтобы по умолчанию функция не запускала никаких особых ситуаций. Но тогда пришлось бы описывать свои особые ситуации практически для каждой функции Это, как правило, требовало бы ее перетрансляции, а кроме того препятствовало бы общению с функциями, написанными на других языках. В результате программист стал бы стремиться отключить механизм особых ситуаций и писал бы излишние операторы, чтобы обойти их. Пользователь считал бы такие программы надежными, поскольку мог не заметить подмены, но это было бы совершенно неоправдано.
9.6.1 Неожиданные особые ситуации
Если к описанию особых ситуаций относиться не достаточно серьезно, то результатом может быть вызов unexpected(), что нежелательно во всех случая, кроме отладки. Избежать вызова unexpected() можно, если хорошо организовать структуру особых ситуации и описание интерфейса. С другой стороны, вызов unexpected() можно перехватить и сделать его безвредным. Если компонент Y хорошо разработан, все его особые ситуации могут быть только производными одного класса, скажем Yerr. Поэтому, если есть описание class someYerr : public Yerr { /* ... */ };то функция, описанная какvoid f() throw (Xerr, Yerr, IOerr);будет передавать любую особую ситуацию типа Yerr вызывающей функции. В частности, обработка особой ситуации типа someYerr в f() сведется к передаче ее вызывающей f() функции. Бывает случаи, когда окончание программы при появлении неожиданной особой ситуации является слишком строгим решением. Допустим функция g() написана для несетевого режима в распределенной системе. Естественно, в g() ничего неизвестно об особых ситуациях, связанных с сетью, поэтому при появлении любой из них вызывается unexpected(). Значит для использования g() в распределенной системе нужно предоставить обработчик сетевых особых ситуаций или переписать g(). Если допустить, что переписать g() невозможно или нежелательно, проблему можно решить, переопределив действие функции unexpected(). Для этого служит функция set_unexpected(). Вначале мы определим класс, который позволит нам применить для функций unexpected() метод "запроса ресурсов путем инициализации" :
typedef void(*PFV)();Теперь мы определим функцию, которая должна в нашем примере заменить unexpected():
PFV set_unexpected(PFV);
class STC { // класс для сохранения и восстановления
PFV old; // функций unexpected()
public:
STC(PFV f) { old = set_unexpected(f); }
~STC() { set_unexpected(old); }
};
void rethrow() { throw; } // перезапуск всех сетевых
// особых ситуацийНаконец, можно дать вариант функции g(), предназначенный для работы в сетевом режиме:void networked_g()В предыдущем разделе было показано, что unexpected() потенциально вызывается из обработчика catch (...). Значит в нашем случае обязательно произойдет повторный запуск особой ситуации. Повторный запуск, когда особая ситуация не запускалась, приводит к вызову terminate(). Поскольку обработчик catch (...) находится вне той области видимости, в которой была запущена сетевая особая ситуация, бесконечный цикл возникнуть не может.
{
STC xx(&rethrow); // теперь unexpected() вызывает rethrow()
g();
}
Есть еще одно, довольно опасное, решение, когда на неожиданную особую ситуацию просто "закрывают глаза":
void muddle_on() { cerr << "не замечаем особой ситуации\n"; }
// ...
STC xx(&muddle_on); // теперь действие unexpected() сводится
// просто к печати сообщенияТакое переопределение действия unexpected() позволяет нормально вернуться из функции, обнаружившей неожиданную особую ситуацию. Несмотря на свою очевидную опасность, это решение используется. Например, можно "закрыть глаза" на особые ситуации в одной части системы и отлаживать другие ее части. Такой подход может быть полезен в процессе отладки и развития системы, перенесенной с языка программирования без особых ситуаций. Все-таки, как правило лучше, если ошибки проявляются как можно раньше. Возможно другое решение, когда вызов unexpected() преобразуется в запуск особой ситуации Fail (неудача):
void fail() { throw Fail; }
// ...
STC yy(&fail);При таком решении вызывающая функция не должна подробно разбираться в возможном результате вызываемой функции: эта функции завершится либо успешно (т.е. возвратится нормально), либо неудачно (т.е. запустит Fail). Очевидный недостаток этого решения в том, что не учитывается дополнительная информация, которая может сопровождать особую ситуацию. Впрочем, при необходимости ее можно учесть, если передавать информацию вместе с Fail.9.7 Неперехваченные особые ситуации
Если особая ситуация запущена и не перехвачена, то вызывается функция terminate(). Она же вызывается, когда система поддержки особых ситуаций обнаруживает, что структура стека нарушена, или когда в процессе обработки особой ситуации при раскручивании стека вызывается деструктор, и он пытается завершить свою работу, запустив особую ситуацию.Действие terminate() сводится к выполнению самой последней функции, заданной как параметр для set_terminate():
typedef void (*PFV)();
PFV set_terminate(PFV);
Функция set_terminate() возвращает указатель на ту функцию, которая была задана как параметр в предыдущем обращении к ней. Необходимость такой функции как terminate() объясняется тем, что иногда вместо механизма особых ситуаций требуются более грубые приемы. Например, terminate() можно использовать для прекращения процесса, а, возможно, и для повторного запуска системы. Эта функция служит экстренным средством, которое применяется, когда отказала стратегия обработки ошибок, рассчитанная на особые ситуации, и самое время применить стратегию более низкого уровня.
Функция unexpected() используется в сходных, но не столь серьезных случаях, а именно, когда функция запустила особую ситуацию, не указанную в ее описании. Действие функции unexpected() сводится к выполнению самой последней функции, заданной как параметр для функции set_unexpected(). По умолчанию unexpected() вызывает terminate(), а та, в свою очередь, вызывает функцию abort(). Предполагается, что такое соглашение устроит большинство пользователей. Предполагается, что функция terminate() не возвращается в обратившеюсяней функцию.
Напомним, что вызов abort() свидетельствует о ненормальном завершении программы. Для нормального выхода из программы используется функция exit(). Она возвращает значение, которое показывает окружающей системе насколько корректно закончилась программа.
9.8 Другие способы обработки ошибок
Механизм особых ситуаций нужен для того, чтобы из одной части программы можно было сообщить в другую о возникновении в первой "особой ситуации". При этом предполагается, что части программы написаны независимо друг от друга, и в той части, которая обрабатывает особую ситуацию, возможна осмысленная реакция на ошибку.Как же должен быть устроен обработчик особой ситуации? Приведем несколько вариантов:
int f(int arg)Укажем, что в обработчике доступны переменные из области видимости, содержащей проверяемый блок этого обработчика. Переменные, описанные в других обработчиках или других проверяемых блоках, конечно, недоступны:
{
try {
g(arg);
}
catch (x1) {
// исправить ошибку и повторить
g(arg);
}
catch (x2) {
// произвести вычисления и вернуть результат
return 2;
}
catch (x3) {
// передать ошибку
throw;
}
catch (x4) {
// вместо x4 запустить другую особую ситуацию
throw xxii;
}
catch (x5) {
// исправить ошибку и продолжить со следующего оператора
}
catch (...) {
// отказ от обработки ошибки
terminate();
}
// ...
}
void f()Нужна общая стратегия для эффективного использования обработчиков в программе. Все компоненты программы должны согласованно использовать особые ситуации и иметь общую часть для обработки ошибок. Механизм обработки особых ситуаций является нелокальным по своей сути, поэтому так важно придерживаться общей стратегии. Это предполагает, что стратегия обработки ошибок должна разрабатываться на самых ранних стадиях проектах. Кроме того, эта стратегия должна быть простой (по сравнению со сложностью всей программы) и ясной. Последовательно проводить сложную стратегию в такой сложной по своей природе области программирования, как восстановление после ошибок, будет просто невозможно.
{
int i1;
// ...
try {
int i2;
// ...
}
catch (x1) {
int i3;
// ...
}
catch (x4) {
i1 = 1; // нормально
i2 = 2; // ошибка: i2 здесь невидимо
i3 = 3; // ошибка: i3 здесь невидимо
}
}
Прежде всего стоит сразу отказаться от того, что одно средство или один прием можно применять для обработки всех ошибок. Это только усложнит систему. Удачная система, обладающая устойчивостью к ошибкам, должна строиться как многоуровневая. На каждом уровне надо обрабатывать настолько много ошибок, насколько это возможно без нарушения структуры системы, оставляя обработку других ошибок более высоким уровням. Назначение terminate() поддержать такой подход, предоставляя возможность экстренного выхода из такого положения, когда нарушен сам механизм обработки особых ситуаций, или когда он используется полностью, но особая ситуация оказалась неперехваченной. Функция unexpected() предназначена для выхода из такого положения, когда не сработало основанное на описании всех особых ситуаций средство защиты. Это средство можно представлять как брандмауер, т.е. стену, окружающую каждую функцию, и препятствующую распространению ошибки. Попытка проводить в каждой функции полный контроль, чтобы иметь гарантию, что функция либо успешно завершится, либо закончится неудачно, но одним из определенных и корректных способов, не может принести успех. Причины этого могут быть различными для разных программ, но для больших программ можно назвать следующие:
[1] работа, которую нужно провести, чтобы гарантировать надежность каждой функции, слишком велика, и поэтому ее не удастся провести достаточно последовательно;
[2] появятся слишком большие дополнительные расходы памяти и времени, которые будут недопустимы для нормальной работы системы (будет тенденция неоднократно проверять на одну и ту же ошибку, а значит постоянно будут проверяться переменные с правильными значениями);
[3] таким ограничениям не будут подчиняться функции, написанные на других языках;
[4] такое понятие надежности является чисто локальным и оно настолько усложняет систему, что становится дополнительной нагрузкой для ее общей надежности.
Однако, разбить программу на отдельные подсистемы, которые либо успешно завершаются, либо заканчиваются неудачно, но одним из определенных и корректных способов, вполне возможно, важно и даже выгодно. Таким свойством должны обладать основные библиотеки, подсистемы или ключевые функции. Описание особых ситуаций должно входить в интерфейсы таких библиотек или подсистем.
Иногда приходится от одного стиля реакции на ошибку переходить на другой. Например, можно после вызова стандартной функции С проверять значение errno и, возможно, запускать особую ситуацию, а можно, наоборот, перехватывать особую ситуацию и устанавливать значение errno перед выходом из стандартной функции в С-программу:
void callC()При такой смене стилей важно быть последовательным, чтобы изменение реакции на ошибку было полным.
{
errno = 0;
cfunction();
if (errno) throw some_exception(errno);
}
void fromC()
{
try {
c_pl_pl_function();
}
catch (...) {
errno = E_CPLPLFCTBLEWIT;
}
}
Обработка ошибок должна быть, насколько это возможно, строго иерархической системой. Если в функции обнаружена динамическая ошибка, то не нужно обращаться за помощью для восстановления или выделения ресурсов к вызывающей функции. При таких обращениях в структуре системы возникают циклические зависимости, в результате чего ее труднее понять, и возможно возникновение бесконечных циклов в процессе обработки и восстановления после ошибки.
Чтобы часть программы, предназначенная для обработки ошибок была более упорядоченной, стоит применять такие упрощающие дело приемы, как "запрос ресурсов путем инициализации", и исходить из таких упрощающих дело допущений, что "особые ситуации являются ошибками".
9.9 Упражнения
1. (*2) Обобщите класс STC до шаблона типа, который позволяет хранить и устанавливать функции разных типов.2. (*3) Дополните класс CheckedPtrToT из $$7.10 до шаблона типа, в котором особые ситуации сигнализируют о динамических ошибках.
3. (*3) Напишите функцию find для поиска в бинарном дереве узлов по значению поля типа char*. Если найден узел с полем, имеющим значение "hello", она должна возвращать указатель на него. Для обозначения неудачного поиска используйте особую ситуацию.
4. (*1) Определите класс Int, совпадающий во всем со встроенным типом int за исключением того, что вместо переполнения или потери значимости в этом классе запускаются особые ситуации.
Подсказка: см. $$9.3.2.
5. (*2) Перенесите из стандартного интерфейса С в вашу операционную систему основные операции с файлами: открытие, закрытие, чтение и запись. Реализуйте их как функции на С++ с тем же назначением, что и функций на С, но в случае ошибок запускайте особые ситуации.
6. (*1) Напишите полное определение шаблона типа Vector с особыми ситуациями Range и Size. Подсказка: см. $$9.3.
7. (*1) Напишите цикл для вычисления суммы элементов вектора, определенного в упражнении 6, причем не проверяйте размер вектора.
Почему это плохое решение?
8. (*2.5) Допустим класс Exception используется как базовый для всех классов, задающих особые ситуации. Каков должен быть его вид? Какая от него могла быть польза? Какие неудобства может вызвать требование обязательного использования этого класса?
9. (*2) Напишите класс или шаблон типа, который поможет реализовать обратный вызов.
10. (*2) Напишите класс Lock (замок) для какой-нибудь системы, допускающей параллельное выполнение.
11. (*1) Пусть определена функция
int main() { /* ... */ }
Измените ее так, чтобы в ней перехватывались все особые ситуации, преобразовывались в сообщения об ошибке и вызов abort().
Подсказка: в функции fromC() из $$9.8 учтены не все случаи.
ГЛАВА 10. ПОТОКИ
"Доступно только то, что видимо"Б. Керниган
В языке С++ нет средств для ввода-вывода. Их и не нужно, поскольку такие средства можно простоиэлегантносоздатьнасамомязыке. Описанная здесь библиотека потокового ввода-вывода реализует строгий типовой и вместе с тем гибкий и эффективный способ символьного ввода и вывода целых, вещественных чисел и символьных строк, а также является базой для расширения, рассчитанного на работу с пользовательскими типами данных. Пользовательский интерфейс библиотеки находится в файле <iostream.h>. Эта глава посвящена самой потоковой библиотеке, некоторым способам работы с ней и определенным приемам реализации библиотеки.
10.1 ВВЕДЕНИЕ
Широко известна трудность задачи проектирования и реализации стандартных средств ввода-вывода для языков программирования.
Традиционно средства ввода-вывода былирассчитаныисключительнона небольшоечисло встроенных типов данных. Однако, в нетривиальных программах на С++ есть много пользовательских типов данных, поэтому необходимо предоставить возможность ввода-вывода значений таких типов. Очевидно, что средства ввода-вывода должны быть простыми, удобными, надежными в использовании и, что важнее всего, адекватными. Пока никто не нашел решения, которое удовлетворило бы всех; поэтому необходимо дать возможность пользователю создавать иные средства ввода-вывода, а также расширять стандартные средства ввода-вывода в расчете на определенное применение.
Цель создания С++ была в том, чтобы пользователь мог определить новые типы данных, работа с которыми была бы столь же удобна и эффективна как и со встроенными типами. Таким образом, кажется разумным потребовать, чтобы средства ввода-вывода для С++ программировались с использованием возможностей С++, доступных каждому. Представленные здесь потоковые средства ввода-вывода появились в результате попытки удовлетворить этим требованиям.
Основная задача потоковых средств ввода-вывода - это процесс преобразования объектов определенного типа в последовательность символов и наоборот. Существуют и другие схемы ввода-вывода, но указанная является основной, и если считать символ просто набором битов, игнорируя его естественную связь с алфавитом, то многие схемы двоичного ввода-вывода можно свести к ней. Поэтому программистская суть задачи сводится к описанию связи между объектом определенного типа и бестиповой (что существенно) строкой.
Последующие разделы описывают основные части потоковой библиотеки С++:
10.2 Вывод: То, что для прикладной программы представляется выводом, на самом деле является преобразованием такихобъектовкак int,
char *, complex или Employee_record в последовательность символов. Описываются средства для записи объектов встроенных и пользовательских типов данных.
10.3 Ввод: Описаны функции для ввода символов, строк и значений встроенных и пользовательских типов данных.
10.4 Форматирование: Часто существуют определенные требования к виду вывода, например, int должно печататься десятичными цифрами, указатели в шестнадцатеричной записи, а вещественные числа должны бытьс явно заданной точностью фиксированного размера. Обсуждаются функции форматирования и определенные программистские приемы их создания, в частности, манипуляторы.
10.5 Файлы и потоки:Каждая программа на С++можетиспользоватьпо умолчанию три потока - стандартный вывод (cout), стандартный ввод
(cin) и стандартный поток ошибок (cerr). Чтобы работать с какими-
либо устройствами или файлами надо создать потоки и привязать их к этим устройствам или файлам. Описывается механизм открытия и закрытия файлов и связывания файлов с потоками.
10.6 Ввод-вывод для С: обсуждается функция printf из файла <stdio.h> для С а также связь между библиотекой для С и <iostream.h> для С++.
Укажем, что существует много независимых реализаций потоковой библиотеки ввода-вывода и набор средств, описанных здесь, будет только подмножеством средств, имеющихся в вашей библиотеке. Говорят,
что внутри любой большой программы есть маленькаяпрограмма,которая стремится вырваться наружу. В этой главе предпринята попытка описать как раз маленькую потоковую библиотеку ввода-вывода, которая позволит оценить основные концепции потокового ввода-вывода и познакомить с наиболее полезными средствами. Используя только средства, описанные здесь,можно написать много программ; если возникнет необходимость в более сложных средствах, обратитесь за деталями к вашему руководству по С++. Заголовочный файл <iostream.h> определяет интерфейс потоковой библиотеки. В ранних версиях потоковой библиотеки использовался файл <stream.h>. Если существуют оба файла, <iostream.h> определяет полный набор средств, а <stream.h> определяет подмножество, которое совместимо с ранними, менее богатыми потоковыми библиотеками.
Естественно, для пользования потоковой библиотекой вовсе не нужно знание техники ее реализации, тем более, что техника может быть различной для различных реализаций. Однако, реализация ввода-вывода является задачей, диктующей определенные условия, значит приемы, найденные процессе ее решения, можно применить и для других задач, а само это решение достойно изучения.
10.2 ВЫВОД
Строгую типовуюиединообразнуюработу как со встроенными,так и спользовательскими типамиможнообеспечить,если использовать единственное перегруженное имя функции для различных операций вывода.Например:
put(cerr,"x = "); // cerr - выходной поток ошибокТип аргумента определяет какую функцию надо вызывать в каждом случае. Такой подход применяется в нескольких языках, однако, это слишком длинная запись. За счет перегрузки операции << , чтобы она означала
put(cerr,x);
put(cerr,'\n');
"вывести" ("put to"), можно получить более простую запись и разрешить программисту выводить в одном операторе последовательность объектов, например так:
cerr << "x = " << x << '\n';Здесь cerr обозначает стандартный поток ошибок. Так, если х типа int со значением 123, то приведенный оператор выдаст
x = 123и еще символ конца строки в стандартный поток ошибок. Аналогично, если х имеет пользовательский тип complex со значением (1,2.4), то указанный оператор выдаст
x = (1,2.4)в поток cerr. Такой подход легко использовать пока x такого типа, для которого определена операция <<,а пользователь может просто доопределить << для новых типов.
Мы использовали операцию вывода, чтобы избежать многословности, неизбежной, если применять функцию вывода. Но почему именно символ << ? Невозможно изобрести новую лексему (см. 7.2).Кандидатом для ввода и вывода была операция присваивания, но большинство людей предпочитает, чтобы операции ввода и вывода были различны. Более того, порядок выполнения операции = неподходящий, так cout=a=b означает cout=(a=b). Пробовали использовать операции < и >, но к ним так крепко привязано понятие "меньше чем" и "больше чем", что операции ввода-вывода с ними во всех практически случаях не поддавались прочтению.
Операции << и >> похоже не создают таких проблем. Они асиметричны, что позволяет приписывать им смысл "в" и "из". Они не относятся к числу наиболее часто используемых операций над встроенными типами, а приоритет << достаточно низкий, чтобы писать арифметические выражения в качестве операнда без скобок:
cout << "a*b+c=" << a*b+c << '\n';Скобки нужны, если выражение содержит операции с более низким приоритетом:
cout << "a^b|c=" << (a^b|c) << '\n';Операцию сдвига влево можно использовать в операции вывода, но, конечно, она должна быть в скобках:
cout << "a<<b=" << (a<<b) << '\n';
10.2.1 Вывод встроенных типов
Для управления выводом встроенных типов определяется класс ostream с операцией << (вывести): class ostream : public virtual ios {
// ...
public:
ostream& operator<<(const char*); //строки
ostream& operator<<(char);
ostream& operator<<(short i)
{ return *this << int(i); }
ostream& operator<<(int);
ostream& operator<<(long);
ostream& operator<<(double);
ostream& operator<<(const void*); // указатели
// ...
};Естественно, в классе ostream должен быть набор функций operator<<() для работы с беззнаковыми типами. Функция operator<< возвращает ссылку на класс ostream, из которого она вызывалась, чтобы к ней можно было применить еще раз operator<<. Так, если х типа int, то
cerr << "x = " << x;понимается как
(cerr.operator<<("x = ")).operator<<(x);В частности, это означает, что если несколько объектов выводятся с помощью одного оператора вывода, то они будут выдаваться в естественном порядке: слева - направо. Функция ostream::operator<<(int) выводит целые значения, а функция ostream::operator<<(char) - символьные. Поэтому функция
void val(char c)печатает целые значения символов и с помощью программы
{
cout << "int('"<< c <<"') = " << int(c) << '\n';
}
main()будет напечатано
{
val('A');
val('Z');
}
int('A') = 65
int('Z') = 90Здесь предполагается кодировка символов ASCII, на вашей машине может быть иной результат. Обратите внимание, что символьная константа имеет тип char, поэтому cout<<'Z' напечатает букву Z, а вовсе не целое 90. Функция ostream::operator<<(const void*) напечатает значение указателя в такой записи, которая более подходит для используемой системы адресации. Программа
main()выдаст на машине, используемой автором,
{
int i = 0;
int* p = new int(1);
cout << "local " << &i
<< ", free store " << p << '\n';
}
local 0x7fffead0, free store 0x500cДля других систем адресации могут быть иные соглашения об изображении значений указателей.
Обсуждение базового класса ios отложим до 10.4.1.
10.2.2 Вывод пользовательских типов
Рассмотрим пользовательский тип данных: class complex {
double re, im;
public:
complex(double r = 0, double i = 0) { re=r; im=i; }
friend double real(complex& a) { return a.re; }
friend double imag(complex& a) { return a.im; }
friend complex operator+(complex, complex);
friend complex operator-(complex, complex);
friend complex operator*(complex, complex);
friend complex operator/(complex, complex);
//...
};Для нового типа complex операцию << можно определить так:ostream& operator<<(ostream&s, complex z)и использоватькак operator<< для встроенных типов. Например,
{
return s << '(' real(z) << ',' << imag(z) << ')';
};
main()выдаст
{
complex x(1,2);
cout << "x = " << x << '\n';
}
x = (1,2)Для определения операции вывода над пользовательскими типами данных не нужно модифицировать описание класса ostream, не требуется и доступ к структурам данных, скрытым в описании класса. Последнее очень кстати, поскольку описание класса ostream находится среди стандартных заголовочных файлов, доступ по записи к которым закрыт для большинства пользователей, и изменять которые они вряд ли захотят, даже если бы могли. Это важно и по той причине, что дает защиту от случайной порчи этих структур данных. Кроме того имеется возможность изменить реализацию ostream, не затрагивая пользовательских программ.
10.3 ВВОД
Ввод во многом сходен с выводом. Есть класс istream, который реализует операцию ввода >> ("ввести из" - "input from") для небольшого набора стандартных типов. Для пользовательских типов можно определить функцию operator>>.10.3.1 Ввод встроенных типов
Класс istream определяется следующим образом: class istream : public virtual ios {
//...
public:
istream& operator>>(char*); // строка
istream& operator>>(char&); // символ
istream& operator>>(short&);
istream& operator>>(int&);
istream& operator>>(long&);
istream& operator>>(float&);
istream& operator>>(double&);
//...
};Функции ввода operator>> определяются так:istream& istream::operator>>(T& tvar)Теперь можно ввести в VECTOR последовательность целых, разделяемых пробелами, с помощью функции:
{
// пропускаем обобщенные пробелы
// каким-то образом читаем T в`tvar'
return *this;
}
int readints(Vector<int>& v)Появление значения с типом, отличным от int, приводит к прекращению операции ввода, и цикл ввода завершается. Так, если мы вводим
// возвращаем число прочитанных целых
{
for (int i = 0; i<v.size(); i++)
{
if (cin>>v[i]) continue;
return i;
}
// слишком много целых для размера Vector
// нужна соответствующая обработка ошибки
}
1 2 3 4 5. 6 7 8.
то функция readints() прочитает пять целых чисел
1 2 3 4 5
Символ точка останется первым символом, подлежащим вводу. Под пробелом, как определено в стандарте С, понимается обобщенный пробел, т.е. пробел, табуляция, конец строки, перевод строки или возврат каретки. Проверка на обобщенный пробел возможна с помощью функции isspace() из файла <ctype.h>.
В качестве альтернативы можно использовать функции get():
class istream : public virtual ios {
//...
istream& get(char& c); // символ
istream& get(char* p, int n, char ='n'); // строка
};В них обобщенный пробел рассматривается как любой другой символ и они предназначены для таких операций ввода, когда не делается никаких предположений о вводимых символах. Функция istream::get(char&) вводит один символ в свой параметр. Поэтому программу посимвольного копирования можно написать так:
main()Такая запись выглядит несимметрично, и у операции >> для вывода символов есть двойник под именем put(), так что можно писать и так:
{
char c;
while (cin.get(c)) cout << c;
}
main()Функция с тремя параметрами istream::get() вводит в символьный вектор не менее n символов, начиная с адреса p. При всяком обращении к get() все символы, помещенные в буфер (если они были), завершаются 0, поэтому если второй параметр равен n, то введено не более n-1 символов. Третий параметр определяет символ, завершающий ввод. Типичное использование функции get() с тремя параметрами сводится к чтению строки в буфер заданного размера для ее дальнейшего разбора, например так:
{
char c;
while (cin.get(c)) cout.put(c);
}
void f()Операция cin>>buf подозрительна, поскольку строка из более чем 99 символов переполнит буфер. Если обнаружен завершающий символ, то он остается в потоке первым символом подлежащим вводу. Это позволяет проверять буфер на переполнение:
{
char buf[100];
cin >> buf; // подозрительно
cin.get(buf,100,'\n'); // надежно
//...
}
void f()Естественно, существует версия get() для типа unsigned char.
{
char buf[100];
cin.get(buf,100,'\n'); // надежно
char c;
if (cin.get(c) && c!='\n') {
// входная строка больше, чем ожидалось
}
//...
}
В стандартном заголовочном файле <ctype.h> определены несколько функций, полезных для обработки при вводе:
int isalpha(char) // 'a'..'z' 'A'..'Z'Все они, кроме isascii(), работают с помощью простого просмотра, используя символ как индекс в таблице атрибутов символов. Поэтому вместо выражения типа
int isupper(char) // 'A'..'Z'
int islower(char) // 'a'..'z'
int isdigit(char) // '0'..'9'
int isxdigit(char) // '0'..'9' 'a'..'f' 'A'..'F'
int isspace(char) // ' ' '\t' возвращает конец строки
// и перевод формата
int iscntrl(char) // управляющий символ в диапазоне
// (ASCII 0..31 и 127)
int ispunct(char) // знак пунктуации, отличен от приведенных выше
int isalnum(char) // isalpha() | isdigit()
int isprint(char) // видимый: ascii ' '..'~'
int isgraph(char) // isalpha() | isdigit() | ispunct()
int isascii(char c) { return 0<=c && c<=127; }
(('a'<=c && c<='z') || ('A'<=c && c<='Z')) // буквакоторое не только утомительно писать, но оно может быть и ошибочным (на машине с кодировкой EBCDIC оно задает не только буквы), лучше использовать вызов стандартной функции isalpha(), который к тому же более эффективен. В качестве примера приведем функцию eatwhite(), которая читает из потока обобщенные пробелы:istream& eatwhite(istream& is)В ней используется функция putback(), которая возвращает символ в поток, и он становится первым подлежащим чтению.
{
char c;
while (is.get(c)) {
if (isspace(c)==0) {
is.putback(c);
break;
}
}
return is;
}
10.3.2 Состояния потока
С каждым потоком (istream или ostream) связано определенное состояние. Нестандартные ситуации и ошибки обрабатываются с помощью проверки и установки состояния подходящим образом. Узнать состояние потока можно с помощью операций над классом ios: class ios { //ios является базовым для ostream и istream
//...
public:
int eof() const; // дошли до конца файла
int fail() const; // следующая операция будет неудачна
int bad() const; // поток испорчен
int good() const; // следующая операция будет успешной
//...
};Последняя операция ввода считается успешной, если состояние задается good() или eof(). Если состояние задается good(), то последующая операция ввода может быть успешной, в противном случае она будет неудачной. Применение операции ввода к потоку в состоянии, задаваемом не good(), считается пустой операцией. Если произошла неудача при попытке чтения в переменную v, то значение v не изменилось (оно не изменится, если v имеет тип, управляемый функциями члена из istream или ostream). Различие между состояниями, задаваемыми как fail() или как bad() уловить трудно, и оно имеет смысл только для разработчиков операций ввода. Если состояние есть fail(), то считается, что поток не поврежден, и никакие символы не пропали; о состоянии bad() ничего сказать нельзя. Значения, обозначающие эти состояния, определены в классе ios:
class ios {
//...
public:
enum io_state {
goodbit=0,
eofbit=1,
filebit=2,
badbit=4,
};
//...
};Истинные значения состояний зависят от реализации, и указанные значения приведены только, чтобы избежать синтаксически неправильных конструкций. Проверять состояние потока можно следующим образом: switch (cin.rdstate()) {
case ios::goodbit:
// последняя операция с cin была успешной
break;
case ios::eofbit:
// в конце файла
break;
case ios::filebit:
// некоторый анализ ошибки
// возможно неплохой
break;
case ios::badbit:
// cin возможно испорчен
break;
}В более ранних реализациях для значений состояний использовались глобальные имена. Это приводило к нежелательному засорению пространства именования, поэтому новые имена доступны только в пределах класса ios. Если вам необходимо использовать старые имена в сочетании с новой библиотекой, можно воспользоваться следующими определениями:const int _good = ios::goodbit;Разработчики библиотек должны заботится о том, чтобы не добавлять новых имен к глобальному пространству именования. Если элементы перечисления входят в общий интерфейс библиотеки, они всегда должны использоваться в классе с префиксами, например, как ios::goodbit и ios::io_state.
const int _bad = ios::badbit;
const int _file = ios::filebit;
const int _eof = ios::eofbit;
typedef ios::io_state state_value ;
Для переменной любого типа, для которого определены операции < и >>, цикл копирования записывается следующим образом:
while (cin>>z) cout << z << '\n';Если поток появляется в условии, то проверяется состояние потока, и условие выполняется (т.е. результат его не 0) только для состояния good(). Как раз в приведенном выше цикле проверяется состояние потока
istream, что является результатом операции cin>>z. Чтобы узнать, почему произошла неудача в цикле или условии, надо проверить состояние. Такая проверка для потока реализуется с помощью операции приведения (7.3.2).
Так, если z является символьным вектором, то в приведенном цикле читается стандартный ввод и выдается для каждой строки стандартного вывода по одному слову (т.е. последовательности символов, не являющихся обобщенными пробелами). Если z имеет тип complex, то в этом цикле с помощью операций, определенных в 10.2.2 и 10.2.3, будут копироваться комплексные числа. Шаблонную функцию копирования для потоков со значениями произвольного типа можно написать следующим образом:
complex z;Поскольку надоедает проверять на корректность каждую операцию ввода-вывода, то распространенным источником ошибок являются именно те места в программе, где такой контроль существенен. Обычно операции вывода не проверяют, но иногда они могут завершиться неудачно. Потоковый ввод-вывод разрабатывался из того принципа, чтобы сделать исключительные ситуации легкодоступными, и тем самым упростить обработку ошибок в процессе ввода-вывода.
iocopy(z,cin,cout); // копирование complex
double d;
iocopy(d,cin,cout); // копирование double
char c;
iocopy(c,cin,cout); // копирование char
10.3.3 Ввод пользовательских типов
Операцию ввода для пользовательского типа можно определить в точности так же, как и операцию вывода, но для операции ввода существенно, чтобы второй параметр имел тип ссылки, например:istream& operator>>(istream& s, complex& a)Несмотря на сжатость кода, обрабатывающего ошибки, на самом деле учитывается большая часть ошибок. Инициализация локальной переменной с нужна для того, чтобы в нее не попало случайное значение, например '(', в случае неудачной операции. Последняя проверка состояния потока гарантирует, что параметр a получит значение только при успешном вводе.
/*
формат input рассчитан на complex; "f" обозначает float:
f
( f )
( f , f )
*/
{
double re = 0, im = 0;
char c = 0;
s >> c;
if (c == '(') {
s >> re >> c;
if (c == ',') s >> im >> c;
if (c != ')') s.clear(ios::badbit); // установим состояние
}
else {
s.putback(c);
s >> re;
}
if (s) a = complex(re,im);
return s;
}
Операция, устанавливающая состояние потока, названа clear() здесь clear - ясный, правильный), поскольку чаще всего она используется для восстановления состояния потока как good(); значением по умолчанию для параметра ios::clear() является ios::goodbit.
10.4 Форматирование
Все примеры из 10.2 содержали неформатированный вывод, который являлся преобразованием объекта в последовательность символов, задаваемую стандартными правилами, длина которой также определяется этими правилами. Часто программистам требуются более развитые возможности. Так, возникает потребность контролировать размер памяти, необходимой для операции вывода, и формат, используемый для выдачи чисел. Точно так же допустимо управление некоторыми аспектами ввода.10.4.1 Класс ios
Большинство средств управления вводом-выводом сосредоточены в классе ios, который является базовым для ostream и istream. По сути здесь находится управление связью между istream или ostream и буфером,используемым для операций ввода-вывода. Именнокласс ios контролирует: как символы попадают в буфер и как они выбираются оттуда. Так, в классе ios есть член, содержащий информацию об используемой при чтении или записи целых чисел системы счисления (десятичная, восьмеричная или шестнадцатеричная), оточностивещественных чисел и т.п., а также функции для проверки и установки значений переменных, управляющих потоком.
class ios {
//...
public:
ostream* tie(ostream* s); // связать input и output
ostream* tie(); // возвратить "tie"
int width(int w); // установить поле width
int width() const;
char fill(char); // установить символ заполнения
char fill() const; // вернуть символ заполнения
long flags(long f);
long flags() const;
long setf(long setbits, long field);
long setf(long);
long unsetf(long);
int precision(int); // установить точность для float
int precision() const;
int rdstate(); const; // состояния потоков, см. $$10.3.2
int eof() const;
int fail() const;
int bad() const;
int good() const;
void clear(int i=0);
//...
};В 10.3.2 описаны функции, работающие с состоянием потока, остальные приведены ниже.10.4.1.1 Связывание потоков
Функция tie() может установить и разорвать связь между ostream иistream. Рассмотрим пример:
main()Как можно гарантировать, что приглашение Password: появится на экране прежде, чем выполниться операция чтения? Вывод в cout и ввод из cin буферизуются, причем независимо, поэтому Password: появится только по завершении программы, когда закроется буфер вывода.
{
String s;
cout << "Password: ";
cin >> s;
// ...
}
Решение состоит в том, чтобы связать cout и cin с помощью операции cin.tie(cout). Если ostream связан с потоком istream, то буфер вывода выдается при каждой операции ввода над istream. Тогда операции
cout << "Password: ";эквивалентны
cin >> s;
cout << "Password: ";Обращение is.tie(0) разрывает связь между потоком is и потоком, с которым он был связан, если такой был. Подобно другим потоковым функциям, устанавливающим определенное значение, tie(s) возвращает предыдущее значение, т.е. значение связанного потока перед обращением или 0. Вызов без параметра tie() возвращает текущее значение.
cout.flush();
cin >> s;
10.4.1.2 Поля вывода
Функция width() устанавливает минимальное число символов, использующееся в последующей операции вывода числа или строки. Так в результате следующих операцийcout.width(4);получим число 12 в поле размером 4 символа, т.е.
cout << '(' << 12 << ')';
( 12)
Заполнение поля заданными символами или выравнивание можно установить с помощью функции fill(), например:
cout.width(4);напечатает
cout.fill('#');
cout << '(' << "ab" << ')';
(##ab)
По умолчанию поле заполняется пробелами, а размер поля по умолчанию есть 0, что означает "столько символов, сколько нужно". Вернуть размеру поля стандартное значение можно с помощью вызова
cout.width(0); // ``столько символов, сколько надо''Функция width() задает минимальное число символов. Если появится больше символов, они будут напечатаны все, поэтому
cout.width(4);напечатает
cout << '(' << "121212" << ")\n";
(121212)
Причина, по которой разрешено переполнение поля, а не усечение вывода, в том, чтобы избежать зависания при выводе. Лучше получить правильную выдачу, выглядящую некрасиво, чем красивую выдачу, являющуюся неправильной.
Вызов width() влияет только на одну следующую за ним операцию вывода, поэтому
cout.width(4);напечатает
cout.fill('#');
cout << '(' << 12 << "),(" << '(' <<12 << ")\n";
(##12),(12)
а не
(##12),(##12)
как можно было бы ожидать. Однако, заметьте, что если бы влияние распространялось на все операции вывода чисел и строк, получился бы еще более неожиданный результат:
(##12#),(##12#
)
С помощью стандартного манипулятора, показанного в 10.4.2.1, можно более элегантно задавать размера поля вывода.
10.4.1.3 Состояние формата
В классе ios содержится состояние формата, которое управляется функциями flags() и setf(). По сути эти функции нужны, чтобы установить или отменить следующие флаги: class ios {
public:
// управляющие форматом флаги:
enum {
skipws=01, // пропуск обобщенных пробелов для input
// поле выравнивания:
left=02, // добавление перед значением
right=04, // добавление после значения
internal=010, // добавление между знаком и значением
// основание целого:
dec=020, // восьмеричное
oct=040, // десятичное
hex=0100, // шестнадцатеричное
showbase=0200, // показать основание целого
showpoint=0400, // выдать нули в конце
uppercase=01000, // 'E', 'X' , а не 'e', 'x'
showpos=02000, // '+' для положительных чисел
// запись числа типа float:
scientific=04000, // .dddddd Edd
fixed=010000, // dddd.dd
// сброс в выходной поток:
unitbuf=020000, // после каждой операции
stdio=040000 // после каждого символа
};
//...
};Смысл флагов будет разъяснен в последующих разделах. Конкретные значения флагов зависят от реализации и даны здесь только для того, чтобы избежать синтаксически неверных конструкций. Определение интерфейса как набора флагов и операций для их установки или отмены - это оцененный временем, хотя и несколько устаревший прием. Основное его достоинство в том, что пользователь может собрать воедино набор флагов, например, так:const int my_io_options =Такое множество флагов можно задавать как параметр одной операции
ios::left|ios::oct|ios::showpoint|ios::fixed;
cout.flags(my_io_options);а также просто передавать между функциями одной программы:
void your_function(int ios_options);Множество флагов можно установить с помощью функции flags(), например:
void my_function()
{
// ...
your_function(my_io_options);
// ...
}
void your_function(int ios_options)Функция flags() возвращает старое значение множества флагов. Это позволяет переустановить значения всех флагов, как показано выше, а также задать значение отдельному флагу. Например вызов
{
int old_options = cout.flags(ios_options);
// ...
cout.flags(old_options); // reset options
}
myostream.flags(myostream.flags()|ios::showpos);заставляет класс myostream выдавать положительные числа со знаком + и, в то же время, не меняет значения других флагов. Получается старое значение множества флагов, к которому добавляется с помощью операции | флаг showpos. Функция setf() делает то же самое, поэтому эквивалентная запись имеет вид
myostream.setf(ios::showpos);После установки флаг сохраняет значение до явной отмены. Все-таки управление вводом-выводом с помощью установки и отмены флагов - грубое и ведущее к ошибкам решение. Если только вы тщательно не изучите свое справочное руководство и не будете применять флаги только в простых случаях, как это делается в последующих разделах, то лучше использовать манипуляторы (описанные в 10.4.2.1). Приемы работы с состоянием потока лучше изучить на примере реализации класса, чем изучая интерфейс класса.
10.4.1.4 Вывод целых
Прием задания нового значения множества флагов с помощью операции | и функций flags() и setf() работает только тогда, когда один бит определяет значение флага. Не такая ситуация при задании системы счисления целых или вида выдачи вещественных. Здесь значение, определяющее вид выдачи, нельзя задать одним битом или комбинацией отдельных битов.Решение, принятое в <iostream.h>, сводится к использованию версии функции setf(), работающей со вторым "псевдопараметром", который показывает какой именно флаг мы хотим добавить к новому значению.
Поэтому обращения
cout.setf(ios::oct,ios::basefield); // восьмеричноеустановят систему счисления, не затрагивая других компонентов состояния потока. Если система счисления установлена, она используется до явной переустановки, поэтому
cout.setf(ios::dec,ios::basefield); // десятичное
cout.setf(ios::hex,ios::basefield); // шестнадцатеричное
cout << 1234 << ' '; // десятичное по умолчаниюнапечатает
cout << 1234 << ' ';
cout.setf(ios::oct,ios::basefield); // восьмеричное
cout << 1234 << ' ';
cout << 1234 << ' ';
cout.setf(ios::hex,ios::basefield); // шестнадцатеричное
cout << 1234 << ' ';
cout << 1234 << ' ';
1234 1234 2322 2322 4d2 4d2
Если появится необходимость указывать систему счисления для каждого выдаваемого числа, следует установить флаг showbase. Поэтому, добавив перед приведенными выше обращениями
cout.setf(ios::showbase);мы получим
1234 1234 02322 02322 0x4d2 0x4d2
Стандартные манипуляторы, приведенные в $$10.4.2.1, предлагают более элегантный способ определения системы счисления при выводе целых.
10.4.1.5 Выравнивание полей
С помощью обращений к setf() можно управлять расположением символов в пределах поля:cout.setf(ios::left,ios::adjustfield); // влевоБудет установлено выравнивание в поле вывода, определяемом функцией ios::width(), причем не затрагивая других компонентов состояния потока. Выравнивание можно задать следующим образом:
cout.setf(ios::right,ios::adjustfield); // вправо
cout.setf(ios::internal,ios::adjustfield); // внутреннее
cout.width(4);что выдаст
cout << '(' << -12 << ")\n";
cout.width(4);
cout.setf(ios::left,ios::adjustfield);
cout << '(' << -12 << ")\n";
cout.width(4);
cout.setf(ios::internal,ios::adjustfield);
cout << '(' << -12 << "\n";
( -12)
(-12 )
(- 12)
Если установлен флаг выравнивания internal (внутренний), то символы добавляются между знаком и величиной. Как видно, стандартным является выравнивание вправо.
10.4.1.6 Вывод плавающих чисел
Вывод вещественных величин также управляется с помощью функций, работающих с состоянием потока. В частности, обращения:cout.setf(ios::scientific,ios::floatfield);установят вид печати вещественных чисел без изменения других компонентов состояния потока. Например:
cout.setf(ios::fixed,ios::floatfield);
cout.setf(0,ios::floatfield); // вернуться к стандартному
cout << 1234.56789 << '\n';напечатает
cout.setf(ios::scientific,ios::floatfield);
cout << 1234.56789 << '\n';
cout.setf(ios::fixed,ios::floatfield);
cout << 1234.56789 << '\n';
1234.57
1.234568e+03
1234.567890
После точки печатается n цифр, как задается в обращении
cout.precision(n)По умолчанию n равно 6. Вызов функции precision влияет на все операции ввода-вывода с вещественными до следующего обращения к precision, поэтому
cout.precision(8);выдаст
cout << 1234.56789 << '\n';
cout << 1234.56789 << '\n';
cout.precision(4);
cout << 1234.56789 << '\n';
cout << 1234.56789 << '\n';
1234.5679
1234.5679
1235
1235
Заметьте, что происходит округление, а не отбрасывание дробной части.
Стандартные манипуляторы, введенные в $$10.4.2.1, предлагают более элегантный способ задания формата вывода вещественных.
10.4.2 Манипуляторы
К ним относятся разнообразные операции, которые приходится применять сразу перед или сразу после операции ввода-вывода. Например:cout << x;Если писать отдельные операторы как выше, то логическая связь между операторами неочевидна, а если утеряна логическая связь, программу труднее понять.
cout.flush();
cout << y;
cin.eatwhite();
cin >> x;
Идея манипуляторов позволяет такие операции как flush() или eatwhite() прямо вставлять в список операций ввода-вывода. Рассмотрим операцию flush(). Можно определить класс с операцией operator<<(), в котором вызывается flush():
class Flushtype { };
ostream& operator<<(ostream& os, Flushtype)
{
return flush(os);
}определить объект такого типаFlushtype FLUSH;и добиться выдачи буфера, включив FLUSH в список объектов, подлежащих выводу:
cout << x << FLUSH << y << FLUSH;Теперь установлена явная связь между операциями вывода и сбрасывания буфера. Однако, довольно быстро надоест определять класс и объект для каждой операции, которую мы хотим применить к поточной операции вывода. К счастью, можно поступить лучше. Рассмотрим такую функцию:
typedef ostream& (*Omanip) (ostream&);Здесь операция вывода использует параметры типа "указатель на функцию, имеющую аргумент ostream& и возвращающую ostream&". Отметив, что flush() есть функция типа "функция с аргументом ostream& и возвращающая iostream&", мы можем писать
ostream& operator<<(ostream& os, Omanip f)
{
return f(os);
}
cout << x << flush << y << flush;получив вызов функции flush(). На самом деле в файле <iostream.h> функция flush() описана как
ostream& flush(ostream&);а в классе есть операция operator<<, которая использует указатель на функцию, как указано выше:
class ostream : public virtual ios {
// ...
public:
ostream& operator<<(ostream& ostream& (*)(ostream&));
// ...
};В приведенной ниже строке буфер выталкивается в поток cout дважды в подходящее время:cout << x << flush << y << flush;Похожие определения существуют и для класса istream:
istream& ws(istream& is ) { return is.eatwhite(); }
class istream : public virtual ios {
// ...
public:
istream& operator>>(istream&, istream& (*) (istream&));
// ...
};поэтому в строкеcin >> ws >> x;действительно обобщенные пробелы будут убраны до попытки чтения в x. Однако, поскольку по умолчанию для операции >>пробелы "съедаются" и так, данное применение ws() избыточно.
Находят применение и манипуляторы с параметрами. Например, может появиться желание с помощью
cout << setprecision(4) << angle;напечатать значение вещественной переменной angle с точностью до четырех знаков после точки. Для этого нужно уметь вызывать функцию, которая установит значение переменной, управляющей в потоке точностью вещественных. Это достигается, если определить setprecision(4) как объект, который можно "выводить" с помощью operator<<():
class Omanip_int {
int i;
ostream& (*f) (ostream&,int);
public:
Omanip_int(ostream& (*ff) (ostream&,int), int ii)
: f(ff), i(ii) { }
friend ostream& operator<<(ostream& os, Omanip& m)
{ return m.f(os,m.i); }
};Конструктор Omanip_int хранит свои аргументы в i и f, а с помощью operator<< вызывается f() с параметром i. Часто объекты таких классов называют объект-функция. Чтобы результат строкиcout << setprecision(4) << angleбыл таким, как мы хотели, необходимо чтобы обращение setprecision(4) создавало безымянный объект класса Omanip_int, содержащий значение 4 и указатель на функцию, которая устанавливает в потоке ostream значение переменной, задающей точность вещественных:
ostream& _set_precision(ostream&,int);Учитывая сделанные определения, operator<<() приведет к вызову precision(i). Утомительно определять классы наподобие Omanip_int для всех типов аргументов, поэтомуопределим шаблон типа:
Omanip_int setprecision(int i)
{
return Omanip_int(&_set_precision,i);
}
template<class T> class OMANIP {
T i;
ostream& (*f) (ostream&,T);
public:
OMANIP(ostream (*ff) (ostream&,T), T ii)
: f(ff), i(ii) { }
friend ostream& operator<<(ostream& os, OMANIP& m)
{ return m.f(os,m.i) }
};С помощью OMANIP пример с установкой точности можно сократить так:ostream& precision(ostream& os,int)
{
os.precision(i);
return os;
}
OMANIP<int> setprecision(int i)
{
return OMANIP<int>(&precision,i);
}
В файле <iomanip.h>можно найти шаблон типа OMANIP,его двойник для istream - шаблон типа SMANIP, а SMANIP - двойник для ioss. Некоторые из стандартных манипуляторов,предлагаемых поточной библиотекой, описаны ниже. Отметим,что программист может определить новые необходимые ему манипуляторы, не затрагивая определений istream, ostream, OMANIP или SMANIP.
Идею манипуляторов предложил А. Кениг. Его вдохновили процедуры разметки (layout ) системы ввода-вывода Алгола68. Такая техника имеет много интересных приложений помимо ввода-вывода. Суть ее в том, что создается объект, который можно передавать куда угодно и который используется как функция. Передача объекта является более гибким решением, поскольку детали выполнения частично определяются создателем объекта, а частично тем, кто к нему обращается.
10.4.2.1 Стандартные манипуляторы ввода-вывода
Это следующие манипуляторы:// Simple manipulators:Например,
ios& oct(ios&); // в восьмеричной записи
ios& dec(ios&); // в десятичной записи
ios& hex(ios&); // в шестнадцатеричной записи
ostream& endl(ostream&); // добавить '\n' и вывести
ostream& ends(ostream&); // добавить '\0' и вывести
ostream& flush(ostream&); // выдать поток
istream& ws(istream&); // удалить обобщенные пробелы
// Манипуляторы имеют параметры:
SMANIP<int> setbase(int b);
SMANIP<int> setfill(int f);
SMANIP<int> setprecision(int p);
SMANIP<int> setw(int w);
SMANIP<long> resetiosflags(long b);
SMANIP<long> setiosflags(long b);
cout << 1234 << ' 'напечатает
<< hex << 1234 << ' '
<< oct << 1234 << endl;
1234 4d2 2322
и
cout << setw(4) << setfill('#') << '(' << 12 << ")\n";
cout << '(' << 12 << ")\n";напечатает(##12)
(12)
Не забудьте включить файл <iomanip.h>, если используете манипуляторы с параметрами.
10.4.3 Члены ostream
В классе ostream есть лишь несколько функций для управления выводом, большая часть таких функций находится в классе ios. class ostream : public virtual ios {
//...
public:
ostream& flush();
ostream& seekp(streampos);
ostream& seekp(streamoff, seek_dir);
streampos tellp();
//...
};Как мы уже говорили, функция flush() опустошает буфер в выходной поток. Остальные функции используются для позиционирования в ostream при записи. Окончание на букву p указывает, что именно позиция используется при выдаче символов в заданный поток. Конечно эти функции имеют смысл, только если поток присоединен к чему-либо, что допускает позиционирование, например файл. Тип streampos представляет позицию символа в файле, а тип streamoff представляет смещение относительно позиции, заданной seek_dir. Все они определены в классе ios: class ios {
//...
enum seek_dir {
beg=0, // от начала файла
cur=1, // от текущей позиции в файле
end=2 // от конца файла
};
//...
};Позиции в потоке отсчитываются от 0, как если бы файл был массивом из n символов:char file[n-1];и если fout присоединено к file, то
fout.seek(10);поместит # в file[10].
fout<<'#';
10.4.4 Члены istream
Как и для ostream, большинство функций форматирования и управления вводом находится не в классе iostream, а в базовом классе ios. class istream : public virtual ios {
//...
public:
int peek()
istream& putback(char c);
istream& seekg(streampos);
istream& seekg(streamoff, seek_dir);
streampos tellg();
//...
};Функции позиционирования работают как и их двойники из ostream. Окончание на букву g показывает, что именно позиция используется при вводе символов из заданного потока. Буквы p и g нужны, поскольку мы можем создать производный класс iostreams из классов ostream и istream, и в нем необходимо следить за позициями ввода и вывода. С помощью функции peek() программа может узнать следующий символ, подлежащий вводу, не затрагивая результата последующего чтения. С помощью функции putback(), как показано в $$10.3.3, можно вернуть ненужный символ назад в поток, чтобы он был прочитан в другое время.
10.5 Файлы и потоки
Ниже приведена программа копирования одного файла в другой. Имена файлов берутся из командной строки программы:#include <fstream.h>Для открытия выходного файла создается объект класса ofstream - выходной поток файла, использующий в качестве аргумента имя файла. Аналогично, для открытия входного файла создается объект класса
#include <libc.h>
void error(char* s, char* s2 ="")
{
cerr << s << ' ' << s2 << '\n';
exit(1);
}
int main(int argc, char* argv[])
{
if (argc != 3) error("wrong number of arguments");
ifstream from(argv[1]);
if (!from) error("cannot open input file",argv[1]);
ostream to(argv[2]);
if (!to) error("cannot open output file",argv[2]);
char ch;
while (from.get(ch)) to.put(ch);
if (!from.eof() || to.bad())
error("something strange happened");
return 0;
}
ifstream - входной файловый поток, также использующий в качестве аргумента имя файла. В обоих случаях следуетпроверить состояние созданного объекта, чтобы убедиться в успешном открытии файла, а если это не так, операции завершатся не успешно, но корректно.
По умолчанию ifstream всегда открывается на чтение, а ofstream открывается на запись. В ostream и в istream можно использовать необязательный второй аргумент, указывающий иные режимы открытия:
class ios {
public:
//...
enum open_mode {
in=1, // открыть на чтение
out=2, // открыть как выходной
ate=4, // открыть и переместиться в конец файла
app=010, // добавить
trunc=020, // сократить файл до нулевой длины
nocreate=040, // неудача, если файл не существует
noreplace=0100 // неудача, если файл существует
};
//...
};Настоящие значения для open_mode и их смысл вероятно будут зависеть от реализации. Будьте добры, за деталями обратитесь к руководству по вашей библиотеке или экспериментируйте. Приведенные комментарии могут прояснить их назначение. Например, можно открыть файл с условием, что операция открытия не выполнится, если файл уже не существует:void f()Также можно открыть файл сразу на чтение и запись:
{
ofstream mystream(name,ios::out|ios::nocreate);
if (ofstream.bad()) {
//...
}
//...
}
fstream dictionary("concordance", ios::in|ios::out);Все операции, допустимые для ostream и ostream, можно применять к fstream. На самом деле, класс fstream является производным от iostream, который является, в свою очередь, производным от istream и ostream.Причина, по которой информация по буферизации и форматированию для ostream и istream находится в виртуальном базовом классе ios, в том, чтобы заставить действовать всю эту последовательность производных классов. По этой же причине операции позиционирования в istream и ostream имеют разные имена - seekp() и seekg(). В iostream есть отдельные позиции для чтения и записи.
10.5.1 Закрытие потоков
Файл может быть закрыт явно, если вызвать close() для его потока:mystream.close();Но это неявно делает деструктор потока, так что явный вызов close() может понадобиться, если только файл нужно закрыть до достижения конца области определенности потока.
Здесь возникает вопрос, как реализация может обеспечить создание предопределенных потоков cout, cin и cerr до их первого использования и закрытие их только после последнего использования. Конечно, разные реализации библиотеки потоков из <iostream.h> могут по-разному решать эту задачу. В конце концов, решение - это прерогатива реализации, и оно должно быть скрыто от пользователя. Здесь приводится только один способ, примененный только в одной реализации, но он достаточно общий, чтобы гарантировать правильный порядок создания и уничтожения глобальных объектов различных типов.
Основная идея в том, чтобы определить вспомогательный класс, который по сути служит счетчиком, следящим за тем, сколько раз <iostream.h> был включен в раздельно компилировавшиеся программные файлы:
class Io_init {
static int count;
//...
public:
Io_init();
^Io_init();
};
static Io_init io_init ;Для каждого программного файла определен свой объект с именем io_init. Конструктор для объектов io_init использует Io_init::count как первый признак того, что действительная инициализация глобальных объектов потоковой библиотеки ввода-вывода сделана в точности один раз:Io_init::Io_init()Обратно, деструктор для объектов io_init использует Io_count, как последнее указание на то, что все потоки закрыты:
{
if (count++ == 0) {
// инициализировать cout
// инициализировать cerr
// инициализировать cin
// и т.д.
}
}
Io_init::^Io_init()Это общий прием работы с библиотеками, требующими инициализации и удаления глобальных объектов. Впервые в С++ его применил Д. Шварц. В системах, где при выполнении все программы размещаются в основной памяти, для этого приема нет помех. Если это не так, то накладные расходы, связанные с вызовом в память каждого программного файла для выполнения функций инициализации, будут заметны. Как всегда,
{
if (--count == 0) {
// очистить cout (сброс, и т.д.)
// очистить cerr (сброс, и т.д.)
// очистить cin
// и т.д.
}
}
лучше, по возможности, избегать глобальных объектов. Для классов, в которых каждая операция значительна по объему выполняемой работы, чтобы гарантировать инициализацию, было бы разумно проверять такие первые признаки (наподобие Io_init::count) при каждой операции. Однако, для потоков такой подход был бы излишне расточительным.
10.5.2 Строковые потоки
Как было показано, поток может быть привязан к файлу, т.е. массиву символов, хранящемуся не в основной памяти, а, например, на диске. Точно так же поток можно привязать к массиву символов в основной памяти.Например, можно воспользоваться выходным строковым потоком ostrstream для форматирования сообщений, не подлежащих немедленной печати:
char* p = new char[message_size];С помощью стандартных операций вывода функция do_something может писать в поток ost, передавать ost подчиняющимся ей функциям и т.п. Контроль переполнения не нужен, поскольку ost знает свой размер и при заполнении перейдет в состояние, определяемое fail(). Затем функция display может послать сообщение в "настоящий" выходной поток. Такой прием наиболее подходит в тех случаях, когда окончательная операция вывода предназначена для записи на более сложное устройство, чем традиционное, ориентированное на последовательность строк, выводное устройство. Например, текст из ost может быть помещен в фиксированную область на экране. Аналогично, istrstream является вводным строковым потоком, читающим из последовательности символов, заканчивающейся нулем:
ostrstream ost(p,message_size);
do_something(arguments,ost);
display(p);
void word_per_line(char v[], int sz)Завершающий нуль считается концом файла. Строковые потоки описаны в файле <strstream.h>.
/*
печатать "v" размером "sz" по одному слову в строке
*/
{
istrstream ist(v,sz); // создать istream для v
char b2[MAX]; // длиннее самого длинного слова
while (ist>>b2) cout <<b2 << "\n";
}
10.5.3 Буферизация
Все операции ввода-вывода были определены без всякой связи с типом файла, но нельзя одинаково работать со всеми устройствами без учета алгоритма буферизации. Очевидно, что потоку ostream, привязанному к строке символов, нужен не такой буфер, как ostream, привязанному к файлу. Такие вопросы решаются созданием во время инициализации разных буферов для потоков разных типов. Но существует только один набор операций над этими типами буферов, поэтому в ostream нет функций, код которых учитывает различие буферов. Однако, функции, следящие за переполнением и обращением к пустому буферу, являются виртуальными.Это хороший пример применения виртуальных функций для единообразной работы с эквивалентными логически, но различно реализованными структурами, и они вполне справляются с требуемыми алгоритмами буферизации. Описание буфера потока в файле <iostream.h> может выглядеть следующим образом:
class streambuf { // управление буфером потока
protected:
char* base; // начало буфера
char* pptr; // следующий свободный байт
char* gptr; // следующий заполненный байт
char* eptr; // один из указателей на конец буфера
char alloc; // буфер, размещенный с помощью "new"
//...
// Опустошить буфер:
// Вернуть EOF при ошибке, 0 - удача
virtual int overflow(int c = EOF);
// Заполнить буфер:
// Вернуть EOF в случае ошибки или конца входного потока,
// иначе вернуть очередной символ
virtual int underflow();
//...
public:
streambuf();
streambuf(char* p, int l);
virtual ~streambuf();
int snextc() // получить очередной символ
{
return (++gptr==pptr) ? underflow() : *gptr&0377;
}
int allocate(); // отвести память под буфер
//...
};Подробности реализации класса streambuf приведены здесь только для полноты представления. Не предполагается, что есть общедоступные реализации, использующие именно эти имена. Обратите внимание на определенные здесь указатели, управляющие буфером; с их помощью простые посимвольные операции с потоком можно определить максимально эффективно (и причем однократно) как функции-подстановки. Только функции overflow() и underflow() требует своей реализации для каждого алгоритма буферизации, например: class filebuf : public streambuf {
protected:
int fd; // дескриптор файла
char opened; // признак открытия файла
public:
filebuf() { opened = 0; }
filebuf(int nfd, char* p, int l)
: streambuf(p,l) { /* ... */ }
~filebuf() { close(); }
int overflow(int c=EOF);
int underflow();
filebuf* open(char *name, ios::open_mode om);
int close() { /* ... */ }
//...
};
int filebuf::underflow() // заполнить буфер из "fd"
{
if (!opened || allocate()==EOF) return EOF;
int count = read(fd, base, eptr-base);
if (count < 1) return EOF;
gptr = base;
pptr = base + count;
return *gptr & 0377; // &0377 предотвращает размножение знака
}За дальнейшими подробностями обратитесь к руководству по реализации класса streambuf.10.6 Ввод-вывод в С
Поскольку текст программ на С и на С++ часто путают, то путают иногда и потоковый ввод-вывод С++ и функции ввода-вывода семейства printf для языка С. Далее, т.к. С-функции можно вызывать из программы на С++, то многие предпочитают использовать более знакомые функции ввода-вывода С. По этой причине здесь будет дана основа функций ввода-вывода С.
Обычно операции ввода-вывода на С и на С++ могут идти по очереди на уровне строк. Перемешивание их на уровне посимвольного ввода-вывода возможно для некоторых реализаций, но такая программа может быть непереносимой. Некоторые реализации потоковой библиотеки С++ при допущении ввода-вывода на С требуют вызова статической функции-члена
ios::sync_with_stdio().
В общем, потоковые функции вывода имеют перед стандартной функцией С printf() то преимущество, что потоковые функции обладают определенной типовой надежностью и единообразно определяют вывод объектов предопределенного и пользовательского типов.
Основная функция вывода С есть
int printf(const char* format, ...)и она выводит произвольную последовательность параметров в формате, задаваемом строкой форматирования format. Строка форматирования состоит из объектов двух типов: простые символы, которые просто копируются в выходной поток, и спецификации преобразований, каждая из которых преобразует и печатает очередной параметр.Каждая спецификация преобразования начинается с символа %, например
printf("there were %d members present.",no_of_members);Здесь %d указывает, что no_of_members следует считать целым и печатать как соответствующую последовательность десятичных цифр. Если no_of_members==127, то будет напечатаноthere were 127 members present.
Набор спецификаций преобразований достаточно большой и обеспечивает большую гибкость печати. За символом % может следовать:
- необязательный знак минус, задающий выравнивание влево в указанном поле для преобразованного значения;
d необязательная строка цифр,задающая ширину поля; если в преобразованном значении меньше символов, чем ширина строки, то оно дополнится до ширины поля пробелами слева (или справа, если дана спецификация выравнивания влево); если строка ширины поля начинается с нуля, то дополнение будет проводится нулями, а не пробелами;
. необязательный символ точка служит для отделения ширины поля от последующей строки цифр;
d необязательная строка цифр, задающая точность, которая определяет число цифр после десятичной точки для значений в спецификациях e или f, или же задает максимальное число печатаемых символов строки;
* для задания ширины поля или точности может использоваться * вместо строки цифр. В этом случае должен быть параметр целого типа, который содержит значение ширины поля или точности;
h необязательный символ h указывает, что последующая спецификация d, o, x или u относится к параметру типа короткое целое;
l необязательный символ l указывает, что последующая спецификация d, o, x или u относится к параметру типа длинное целое;
% обозначает, что нужно напечатать сам символ %; параметр не нужен;
c символ, указывающий тип требуемого преобразования. Символы преобразования и их смысл следующие:
d Целый параметр выдается в десятичной записи;
o Целый параметр выдается в восьмеричной записи;
x Целый параметр выдается в шестнадцатеричной записи;
f Вещественный или с двойной точностью параметр выдается в десятичной записивида [-]ddd.ddd, где число цифр после точки равно спецификации точности для параметра. Если точность не задана, печатается шесть цифр; если явно задана точность 0, точка и цифры после нее не печатаются;
e Вещественный или с двойной точностью параметр выдается в десятичной записи вида [-]d.ddde+dd; здесь одна цифра перед точкой, а число цифр после точки равно спецификации точности для параметра; если она не задана печатается шесть цифр;
g Вещественный или с двойной точностью параметр печатается по той спецификации d, f или e, которая дает большую точность при меньшей ширине поля;
c Символьный параметр печатается. Нулевые символы игнорируются;
s Параметр считается строкой (символьный указатель), и печатаются символы из строки до нулевого символа или до достижения числа символов, равного спецификации точности; но, если точность равна 0 или не указана, печатаются все символы до нулевого;
p Параметр считается указателем и его вид на печати зависит от реализации;
u Беззнаковый целый параметр печатается в десятичной записи.
Несуществующее поле или поле с шириной, меньшей реальной, приведет к усечению поля. Дополнение пробелами происходит, если только спецификация ширины поля больше реальной ширины. Ниже приведен более сложный пример:
char* src_file_name;в котором печатается
int line;
char* line_format = "\n#line %d \"%s\"\n";
main()
{
line = 13;
src_file_name = "C++/main.c";
printf("int a;\n");
printf(line_format,line,src_file_name);
printf("int b;\n");
}
int a;Использование printf() ненадежно в том смысле, что нет никакого контроля типов. Так, ниже приведен известный способ получения неожиданного результата - печати мусорного значения или чего похуже:
#line 13 "C++/main.c"
int b;
char x;Однако, эти функции обеспечивают большую гибкость и знакомы программирующим на С.
// ...
printf("bad input char: %s",x);
Как обычно, getchar() позволяет знакомым способом читать символы из входного потока:
int i;:Обратите внимание: чтобы было законным сравнение с величиной EOF типа int при проверке на конец файла, результат getchar() надо помещать в переменную типа int, а не char.
while ((i=getchar())!=EOF) { // символьный ввод C
// используем i
}
За подробностями о вводе-выводе на С отсылаем к вашему руководству по С или книге Кернигана и Ритчи "Язык программирования С".
10.7 Упражнения
1. (*1.5) Читая файл вещественных чисел, составлять из пар прочитанных чисел комплексные числа, записать комплексные числа.
2. (*1.5) Определить тип name_and_address (тип_и_адрес). Определить для него << и >>. Написать программу копирования объектов потока
name_and_address.
3. (*2) Разработать несколько функций для запроса и чтения данных разных типов. Предложения: целое, вещественное число, имя файла, почтовый адрес, дата, личная информация, и т.п. Попытайтесь сделать их устойчивыми к ошибкам.
4. (*1.5) Напишите программу, которая печатает: (1) строчные буквы,
(2) все буквы, (3) все буквы и цифры, (4) все символы, входящие в идентификатор в вашей версии С++, (5) все знаки пунктуации,
(6) целые значения всех управляющих символов, (7) все обобщенные пробелы, (8) целые значения всех обобщенных пробелов, и, наконец,
(9) все изображаемые символы.
5. (*4) Реализуйте стандартную библиотеку ввода-вывода С (<stdio.h>)
с помощью стандартной библиотеки ввода-вывода С++ (<iostream.h>).
6. (*4) Реализуйте стандартную библиотеку ввода-вывода С++
(<iostream.h>) с помощью стандартной библиотеки ввода-вывода С
(<stdio.h>).
7. (*4) Реализуйте библиотеки С и С++ так, чтобы их можно было использовать одновременно.
8. (*2) Реализуйте класс, для которого операция [] перегружена так, чтобы обеспечить произвольное чтение символов из файла.
9. (*3) Повторите упражнение 8, но добейтесь, чтобы операция [] была применима для чтения и для записи. Подсказка: пусть [] возвращает объект "дескриптор типа", для которого присваивание означает: присвоить через дескриптор файлу, а неявное приведение к типу char
означает чтение файла по дескриптору.
10.(*2) Повторите упражнение 9, позволяя операции [] индексировать объекты произвольных типов, а не только символы.
11.(*3.5) Продумайтеи реализуйте операцию форматного ввода. Используйте для задания формата строку спецификаций как в printf(). Должна быть возможностьпопыток применения нескольких спецификаций для одного ввода, чтобы найти требуемый формат. Класс форматного ввода должен быть производным класса istream.
12.(*4) Придумайте (и реализуйте) лучшие форматы ввода.
13.(**2) Определите для вывода манипулятор based с двумя параметрами: система счисления и целое значение, и печатайте целое в представлении, определяемом системой счисления. Например, based(2,9)
напечатает 1001.
14.(**2) Напишите "миниатюрную" систему ввода-вывода, которая реализует классы istream, ostream, ifstream, ofstream и предоставляет функции, такие как operator<<() и operator>>() для целых, и операции, такие как open() и close() для файлов. Используйте исключительные ситуации, а не переменные состояния, для сообщения об ошибках.
15.(**2) Напишите манипулятор, который включает и отключает эхо символа.