ЛИТЕРАЛЫ
В С++ можно задавать значения всех основных типов: символьные константы, целые константы и константы с плавающей точкой. Кроме того, нуль (0) можно использовать как значение указателя произвольного типа, а символьные строки являются константами типа char[]. Есть возможность определить символические константы. Символическая константа - это имя, значение которого в его области видимости изменять нельзя. В С++ символические константы можно задать тремя способами: (1) добавив служебное слово const в определении, можно связать с именем любое значение произвольного типа; (2) множество целых констант можно определить как перечисление; (3) константой является имя массива или функции.
Локальные переменные
Конструктор локальной переменной вызывается каждый раз, когда при выполнении программы встречается ее описание. Деструктор локальной переменной вызывается всякий раз по выходе из блока, где она была описана. Деструкторы для локальных переменных вызываются в порядке, обратном вызову конструкторов при их создании:
void f(int i)
{
table aa;
table bb;
if (i>0) {
table cc;
// ...
}
// ...
}
Здесь aa и bb создаются (именно в таком порядке) при каждом вызове f(), а уничтожаются они при возврате из f() в обратном порядке - bb, затем aa. Если в текущем вызове f() i больше нуля, то cc создается после bb и уничтожается прежде него.
Поскольку aa и bb - объекты класса table, присваивание aa=bb означает копирование по членам bb в aa (см. $$2.3.8). Такая интерпретация присваивания может привести к неожиданному (и обычно нежелательному) результату, если присваиваются объекты класса, в котором определен конструктор:
void h()
{
table t1(100);
table t2 = t1; // неприятность
table t3(200);
t3 = t2; // неприятность
}
В этом примере конструктор table вызывается дважды: для t1 и t3. Он не вызывается для t2, поскольку этот объект инициализируется присваиванием. Тем не менее, деструктор для table вызывается три раза: для t1, t2 и t3! Далее, стандартная интерпретация присваивания - это копирование по членам, поэтому перед выходом из h() t1, t2 и t3 будут содержать указатель на массив имен, память для которого была выделена в свободной памяти при создании t1. Указатель на память, выделенную для массива имен при создании t3, будет потерян. Этих неприятностей можно избежать (см. $$1.4.2 и $$7.6).
Макросредства
Макросредства языка определяются в $$R.16. В С++ они играют гораздо меньшую роль, чем в С. Можно даже дать такой совет: используйте макроопределения только тогда, когда не можете без них обойтись. Вообще говоря, считается, что практически каждое появление макроимени является свидетельством некоторых недостатков языка, программы или программиста. Макросредства создают определенные трудности для работы служебных системных программ, поскольку они перерабатывают программный текст еще до трансляции. Поэтому, если ваша программа использует макросредства, то сервис, предоставляемый такими программами, как отладчик, профилировщик, программа перекрестных ссылок, будет для нее неполным. Если все-таки вы решите использовать макрокоманды, то вначале тщательно изучите описание препроцессора С++ в вашем справочном руководстве и не старайтесь быть слишком умным.
Простое макроопределение имеет вид:
#define имя остаток-строки
В тексте программы лексема имя заменяется на остаток-строки. Например,
объект = имя
будет заменено на
объект = остаток-строки
Макроопределение может иметь параметры. Например:
#define mac(a,b) argument1: a argument2: b
В макровызове mac должны быть заданы две строки, представляющие параметры. При подстановке они заменят a и b в макроопределении mac(). Поэтому строка
expanded = mac(foo bar, yuk yuk)
при подстановке преобразуется в
expanded = argument1: foo bar argument2: yuk yuk
Макроимена нельзя перегружать. Рекурсивные макровызовы ставят перед препроцессором слишком сложную задачу:
// ошибка:
#define print(a,b) cout<<(a)<<(b)
#define print(a,b,c) cout<<(a)<<(b)<<(c)
// слишком сложно:
#define fac(n) (n>1) ?n*fac(n-1) :1
Препроцессор работает со строками и практически ничего не знает о синтаксисе C++, типах языка и областях видимости. Транслятор имеет дело только с уже раскрытым макроопределением, поэтому ошибка в нем может диагностироваться уже после подстановки, а не при определении макроимени. В результате появляются довольно путанные сообщения об ошибках.
Допустимы такие макроопределения:
#define Case break;case
#define forever for(;;)
А вот совершенно излишние макроопределения:
#define PI 3.141593
#define BEGIN {
#define END }
Следующие макроопределения могут привести к ошибкам:
#define SQUARE(a) a*a
#define INCR_xx (xx)++
#define DISP = 4
Чтобы убедиться в этом, достаточно попробовать сделать подстановку в таком примере:
int xx = 0; // глобальный счетчик
void f() {
int xx = 0; // локальная переменная
xx = SQUARE(xx+2); // xx = xx +2*xx+2;
INCR_xx; // увеличивается локальная переменная xx
if (a-DISP==b) { // a-=4==b
// ...
}
}
При ссылке на глобальные имена в макроопределении используйте операцию
разрешения области видимости ($$2.1.1), и всюду, где это возможно, заключайте имя параметра макроопределения в скобки. Например:
#define MIN(a,b) (((a)<(b))?(a):(b))
Если макроопределение достаточно сложное, и требуется комментарий к нему, то разумнее написать комментарий вида /* */, поскольку в реализации С++ может использоваться препроцессор С, который не распознает комментарии вида //. Например:
#define m2(a) something(a) /* глубокомысленный комментарий */
С помощью макросредств можно создать свой собственный язык, правда, скорее всего, он будет непонятен другим. Кроме того, препроцессор С предоставляет довольно слабые макросредства. Если ваша задача нетривиальна, вы, скорее всего, обнаружите, что решить ее с помощью этих средств либо невозможно, либо чрезвычайно трудно. В качестве альтернативы традиционному использованию макросредств в язык введены конструкции const, inline и шаблоны типов. Например:
const int answer = 42;
template<class T>
inline T min(T a, T b) { return (a<b)?a:b; }
Манипуляторы
К ним относятся разнообразные операции, которые приходится применять сразу перед или сразу после операции ввода-вывода. Например:
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& operator<<(ostream& os, Omanip f)
{
return f(os);
}
Здесь операция вывода использует параметры типа "указатель на функцию,
имеющую аргумент ostream& и возвращающую ostream&". Отметив, что flush() есть функция типа "функция с аргументом ostream& и возвращающая ostream&", мы можем писать
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);
Omanip_int setprecision(int i)
{
return Omanip_int(&_set_precision,i);
}
Учитывая сделанные определения, operator<<() приведет к вызову precision(i).
Утомительно определять классы наподобие Omanip_int для всех типов аргументов, поэтому определим шаблон типа:
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. Такая техника имеет много интересных приложений помимо ввода-вывода. Суть ее в том, что создается объект, который можно передавать куда угодно и который используется как функция. Передача объекта является более гибким решением, поскольку детали выполнения частично определяются создателем объекта, а частично тем, кто к нему обращается.
Массивы
Для типа T T[size] является типом "массива из size элементов типа T".
Элементы индексируются от 0 до size-1. Например:
float v[3]; // массив из трех чисел с плавающей точкой:
// v[0], v[1], v[2]
int a[2][5]; // два массива, из пяти целых каждый
char* vpc; // массив из 32 символьных указателей
Можно следующим образом записать цикл, в котором печатаются целые значения прописных букв:
extern "C" int strlen(const char*); // из <string.h>
char alpha[] = "abcdefghijklmnopqrstuvwxyz";
main()
{
int sz = strlen(alpha);
for (int i=0; i<sz; i++) {
char ch = alpha[i];
cout << '\''<< ch << '\''
<< " = " <<int(ch)
<< " = 0" << oct(ch)
<< " = 0x" << hex(ch) << '\n';
}
}
Здесь функции oct() и hex() выдают свой параметр целого типа в восьмеричном и шестнадцатеричном виде соответственно. Обе функции описаны в <iostream.h>. Для подсчета числа символов в alpha используется функция strlen() из <string.h>, но вместо нее можно было использовать размер массива alpha ($$2.4.4). Для множества символов ASCII результат будет таким:
'a' = 97 = 0141 = 0x61
'b' = 98 = 0142 = 0x62
'c' = 99 = 0143 = 0x63
...
Отметим, что не нужно указывать размер массива alpha: транслятор установит его, подсчитав число символов в строке, заданной в качестве инициализатора. Задание массива символов в виде строки инициализатора - это удобный, но к сожалению, единственный способ подобного применения строк. Присваивание строки массиву недопустимо, поскольку в языке присваивание массивам не определено, например:
char v[9];
v = "a string"; // ошибка
Классы позволяют реализовать представление строк с большим набором операций (см. $$7.10).
Очевидно, что строки пригодны только для инициализации символьных массивов; для других типов приходится использовать более сложную запись. Впрочем, она может использоваться и для символьных массивов. Например:
int v1[] = { 1, 2, 3, 4 };
int v2[] = { 'a', 'b', 'c', 'd' };
char v3[] = { 1, 2, 3, 4 };
char v4[] = { 'a', 'b', 'c', 'd' };
Здесь v3 и v4 - массивы из четырех ( а не пяти) символов; v4 не оканчивается
нулевым символом, как того требуют соглашение о строках и большинство библиотечных функций. Используя такой массив char мы сами готовим почву для будущих ошибок.
Многомерные массивы представлены как массивы массивов. Однако нельзя при задании граничных значений индексов использовать, как это делается в некоторых языках, запятую. Запятая - это особая операция для перечисления выражений (см. $$3.2.2). Можно попробовать задать такое описание:
int bad[5,2]; // ошибка
или такое
int v[5][2];
int bad = v[4,1]; // ошибка
int good = v[4][1]; // правильно
Ниже описывается массив из двух элементов, каждый из которых является, в свою очередь, массивом из 5 элементов типа char:
char v[2][5];
В следующем примере первый массив инициализируется пятью первыми буквами
алфавита, а второй - пятью младшими цифрами.
char v[2][5] = {
{ 'a', 'b', 'c', 'd', 'e' },
{ '0', '1', '2', '3', '4' }
};
main() {
for (int i = 0; i<2; i++) {
for (int j = 0; j<5; j++)
cout << "v[" << i << "][" << j
<< "]=" << v[i][j] << " ";
cout << '\n';
}
}
В результате получим:
v[0][0]=a v[0][1]=b v[0][2]=c v[0][3]=d v[0][4]=e
v[1][0]=0 v[1][1]=1 v[1][2]=2 v[1][3]=3 v[1][4]=4
Массивы объектов класса
Чтобы можно было описать массив объектов класса с конструктором, этот класс должен иметь стандартный конструктор, т.е. конструктор, вызываемый без параметров. Например, в соответствии с определением
table tbl[10];
будет создан массив из 10 таблиц, каждая из которых инициализируется вызовом table::table(15), поскольку вызов table::table() будет происходить с фактическим параметром 15.
В описании массива объектов не предусмотрено возможности указать параметры для конструктора. Если члены массива обязательно надо инициализировать разными значениями, то начинаются трюки с глобальными или статическими членами.
Когда уничтожается массив, деструктор должен вызываться для каждого элемента массива. Для массивов, которые размещаются не с помощью new, это делается неявно. Однако для размещенных в свободной памяти массивов неявно вызывать деструктор нельзя, поскольку транслятор не отличит указатель на отдельный объект массива от указателя на начало массива, например:
void f()
{
table* t1 = new table;
table* t2 = new table[10];
delete t1; // удаляется одна таблица
delete t2; // неприятность:
// на самом деле удаляется 10 таблиц
}
В данном случае программист должен указать, что t2 - указатель на массив:
void g(int sz)
{
table* t1 = new table;
table* t2 = new table[sz];
delete t1;
delete[] t2;
}
Функция размещения хранит число элементов для каждого размещаемого массива. Требование использовать для удаления массивов только операцию delete[] освобождает функцию размещения от обязанности хранить счетчики числа элементов для каждого массива. Исполнение такой обязанности в реализациях С++ вызывало бы существенные потери времени и памяти и нарушило совместимость с С.
Механизм вызова
Основное средство поддержки объектно-ориентированного программирования - это механизм вызова функции-члена для данного объекта, когда истинный тип его на стадии трансляции неизвестен. Пусть, например, есть указатель p. Как происходит вызов p->rotate(45)? Поскольку С++ базируется на статическом контроле типов, задающее вызов выражение имеет смысл только при условии, что функция rotate() уже была описана. Далее, из обозначения p->rotate() мы видим, что p является указателем на объект некоторого класса, а rotate должна быть членом этого класса. Как и при всяком статическом контроле типов проверка корректности вызова нужна для того, чтобы убедиться (насколько это возможно на стадии трансляции), что типы в программе используются непротиворечивым образом. Тем самым гарантируется, что программа свободна от многих видов ошибок.
Итак, транслятору должно быть известно описание класса, аналогичное тем, что приводились в $$1.2.5:
class shape
{
// ...
public:
// ...
virtual void rotate ( int );
// ...
};
а указатель p должен быть описан, например, так:
T * p;
где T - класс shape или производный от него класс. Тогда транслятор видит, что класс объекта, на который настроен указатель p, действительно имеет функцию rotate(), а функция имеет параметр типа int. Значит, p->rotate(45) корректное выражение.
Поскольку shape::rotate() была описана как виртуальная функция, нужно использовать механизм вызова виртуальной функции. Чтобы узнать, какую именно из функций rotate следует вызвать, нужно до вызова получить из объекта некоторую служебную информацию, которая была помещена туда при его создании. Как только установлено, какую функцию надо вызвать, допустим circle::rotate, происходит ее вызов с уже упоминавшимся контролем типа. Обычно в качестве служебной информации используется таблица адресов функций, а транслятор преобразует имя rotate в индекс этой таблицы. С учетом этой таблицы объект типа shape можно представить так:
center
vtbl:
color &X::draw
&Y::rotate
...
...
Функции из таблицы виртуальных функций vtbl позволяют правильно работать с объектом даже в тех случаях, когда в вызывающей функции неизвестны ни таблица vtbl, ни расположение данных в части объекта, обозначенной ... . Здесь как X и Y обозначены имена классов, в которые входят вызываемые функции. Для объекта circle оба имени X и Y есть circle. Вызов виртуальной функции может быть по сути столь же эффективен, как вызов обычной функции.
Множественное наследование
Если класс A является базовым классом для B, то B наследует атрибуты A. т.е. B содержит A плюс еще что-то. С учетом этого становится очевидно, что хорошо, когда класс B может наследовать из двух базовых классов A1 и A2. Это называется множественным наследованием.
Приведем некий типичный пример множественного наследования. Пусть есть два библиотечных класса displayed и task. Первый представляет задачи, информация о которых может выдаваться на экран с помощью некоторого монитора, а второй - задачи, выполняемые под управлением некоторого диспетчера. Программист может создавать собственные классы, например, такие:
class my_displayed_task: public displayed, public task
{
// текст пользователя
};
class my_task: public task {
// эта задача не изображается
// на экране, т.к. не содержит класс displayed
// текст пользователя
};
class my_displayed: public displayed
{
// а это не задача
// т.к. не содержит класс task
// текст пользователя
};
Если наследоваться может только один класс, то пользователю доступны только два из трех приведенных классов. В результате либо получается дублирование частей программы, либо теряется гибкость, а, как правило, происходит и то, и другое. Приведенный пример проходит в С++ безо всяких дополнительных расходов времени и памяти по сравнению с программами, в которых наследуется не более одного класса. Статический контроль типов от этого тоже не страдает.
Все неоднозначности выявляются на стадии трансляции:
class task
{
public:
void trace ();
// ...
};
class displayed
{
public:
void trace ();
// ...
};
class my_displayed_task:public displayed, public task
{
// в этом классе trace () не определяется
};
void g ( my_displayed_task * p )
{
p -> trace (); // ошибка: неоднозначность
}
В этом примере видны отличия С++ от объектно-ориентированных диалектов
языка Лисп, в которых есть множественное наследование. В этих диалектах неоднозначность разрешается так: или считается существенным порядок описания, или считаются идентичными объекты с одним и тем же именем в разных базовых классах, или используются комбинированные способы, когда совпадение объектов доля базовых классов сочетается с более сложным способом для производных классов. В С++ неоднозначность, как правило, разрешается введением еще одной функции:
class my_displayed_task:public displayed, public task
{
// ...
public:
void trace ()
{
// текст пользователя
displayed::trace (); // вызов trace () из displayed
task::trace (); // вызов trace () из task
}
// ...
};
void g ( my_displayed_task * p )
{
p -> trace (); // теперь нормально
}
В $$1.5.3 и $$6.2.3 уже говорилось, что у класса может быть несколько
прямых базовых классов. Это значит, что в описании класса после : может быть указано более одного класса. Рассмотрим задачу моделирования, в которой параллельные действия представлены стандартной библиотекой классов task, а сбор и выдачу информации обеспечивает библиотечный класс displayed. Тогда класс моделируемых объектов (назовем его satellite) можно определить так:
class satellite : public task, public displayed {
// ...
};
Такое определение обычно называется множественным наследованием. Обратно, существование только одного прямого базового класса называется единственным наследованием.
Ко всем определенным в классе satellite операциям добавляется объединение операций классов task и displayed:
void f(satellite& s)
{
s.draw(); // displayed::draw()
s.delay(10); // task::delay()
s.xmit(); // satellite::xmit()
}
С другой стороны, объект типа satellite можно передавать функциям с параметром типа task или displayed:
void highlight(displayed*);
void suspend(task*);
void g(satellite* p)
{
highlight(p); // highlight((displayed*)p)
suspend(p); // suspend((task*)p);
}
Очевидно, реализация этой возможности требует некоторого (простого) трюка от транслятора: нужно функциям с параметрами task и displayed передать разные части объекта типа satellite.
Для виртуальных функций, естественно, вызов и так выполнится правильно:
class task {
// ...
virtual pending() = 0;
};
class displayed {
// ...
virtual void draw() = 0;
};
class satellite : public task, public displayed {
// ...
void pending();
void draw();
};
Здесь функции satellite::draw() и satellite::pending() для объекта типа satellite будут вызываться так же, как если бы он был объектом типа displayed или task, соответственно.
Отметим, что ориентация только на единственное наследование ограничивает возможности реализации классов displayed, task и satellite. В таком случае класс satellite мог бы быть task или displayed, но не то и другое вместе (если, конечно, task не является производным от displayed или наоборот). В любом случае теряется гибкость.
Множественное вхождение базового класса
Возможность иметь более одного базового класса влечет за собой возможность неоднократного вхождения класса как базового. Допустим, классы task и displayed являются производными класса link, тогда в satellite он будет входить дважды:
class task : public link {
// link используется для связывания всех
// задач в список (список диспетчера)
// ...
};
class displayed : public link {
// link используется для связывания всех
// изображаемых объектов (список изображений)
// ...
};
Но проблем не возникает. Два различных объекта link используются для различных списков, и эти списки не конфликтуют друг с другом. Конечно, без риска неоднозначности нельзя обращаться к членам класса link, но как это сделать корректно, показано в следующем разделе. Графически объект satellite можно представить так:
Но можно привести примеры, когда общий базовый класс не должен представляться двумя различными объектами (см. $$6.5.3).
Множественные реализации
Основные средства, поддерживающие объектно-ориентированное программирование, а именно: производные классы и виртуальные функции,- можно использовать и для поддержки абстракции данных, если допустить несколько реализаций одного типа. Вернемся к примеру со стеком:
template < class T >
class stack
{
public:
virtual void push ( T ) = 0; // чистая виртуальная функция
virtual T pop () = 0; // чистая виртуальная функция
};
Обозначение =0 показывает, что для виртуальной функции не требуется никакого определения, а класс stack является абстрактным, т.е. он может использоваться только как базовый класс. Поэтому стеки можно использовать, но не создавать:
class cat { /* ... */ };
stack < cat > s; // ошибка: стек - абстрактный класс
void some_function ( stack <cat> & s, cat kitty ) // нормально
{
s.push ( kitty );
cat c2 = s.pop ();
// ...
}
Поскольку интерфейс стека ничего не сообщает о его представлении, от пользователей стека полностью скрыты детали его реализации.
Можно предложить несколько различных реализаций стека. Например, стек может быть массивом:
template < class T >
class astack : public stack < T >
{
// истинное представление объекта типа стек
// в данном случае - это массив
// ...
public:
astack ( int size );
~astack ();
void push ( T );
T pop ();
};
Можно реализовать стек как связанный список:
template < class T >
class lstack : public stack < T >
{
// ...
};
Теперь можно создавать и использовать стеки:
void g ()
{
lstack < cat > s1 ( 100 );
astack < cat > s2 ( 100 );
cat Ginger;
cat Snowball;
some_function ( s1, Ginger );
some_function ( s2, Snowball );
}
О том, как представлять стеки разных видов, должен беспокоиться только
тот, кто их создает (т.е. функция g()), а пользователь стека (т.е. автор функции some_function()) полностью огражден от деталей их реализации. Платой за подобную гибкость является то, что все операции над стеками должны быть виртуальными функциями.
Множественные заголовочные файлы
Разбиение программы в расчете на один заголовочный файл больше подходит для небольших программ, отдельные части которых не имеют самостоятельного назначения. Для таких программ допустимо, что по заголовочному файлу нельзя определить, чьи описания там находятся и по какой причине. Здесь могут помочь только комментарии. Возможно альтернативное решение: пусть каждая часть программы имеет свой заголовочный файл, в котором определяются средства, предоставляемые другим частям. Теперь для каждого файла .c будет свой файл .h, определяющий, что может предоставить первый. Каждый файл .c будет включать как свой файл .h, так и некоторые другие файлы .h, исходя из своих потребностей.
Попробуем использовать такую организацию программы для калькулятора. Заметим, что функция error() нужна практически во всех функциях программы, а сама использует только <iostream.h>. Такая ситуация типична для функций, обрабатывающих ошибки. Следует отделить ее от файла main.c:
// error.h: обработка ошибок
extern int no_of_errors;
extern double error(const char* s);
// error.c
#include <iostream.h>
#include "error.h"
int no_of_errors;
double error(const char* s) { /* ... */ }
При таком подходе к разбиению программы каждую пару файлов .c и .h можно рассматривать как модуль, в котором файл .h задает его интерфейс, а файл .c определяет его реализацию.
Таблица имен не зависит ни от каких частей калькулятора, кроме части обработки ошибок. Теперь этот факт можно выразить явно:
// table.h: описание таблицы имен
struct name {
char* string;
name* next;
double value;
};
extern name* look(const char* p, int ins = 0);
inline name* insert(const char* s) { return look(s,1); }
// table.h: определение таблицы имен
#include "error.h"
#include <string.h>
#include "table.h"
const int TBLSZ = 23;
name* table[TBLSZ];
name* look(const char* p, int ins) { /* ... */ }
Заметьте, что теперь описания строковых функций берутся из включаемого файла <string.h>. Тем самым удален еще один источник ошибок.
// lex.h: описания для ввода и лексического анализа
enum token_value {
NAME, NUMBER, END,
PLUS='+', MINUS='-', MUL='*',
PRINT=';', ASSIGN='=', LP='(', RP= ')'
};
extern token_value curr_tok;
extern double number_value;
extern char name_string[256];
extern token_value get_token();
Интерфейс с лексическим анализатором достаточно запутанный. Поскольку недостаточно соответствующих типов для лексем, пользователю функции get_token() предоставляются те же буферы number_value и name_string, с которыми работает сам лексический анализатор.
// lex.c: определения для ввода и лексического анализа
#include <iostream.h>
#include <ctype.h>
#include "error.h"
#include "lex.h"
token_value curr_tok;
double number_value;
char name_string[256];
token_value get_token() { /* ... */ }
Интерфейс с синтаксическим анализатором определен четко:
// syn.h: описания для синтаксического анализа и вычислений
extern double expr();
extern double term();
extern double prim();
// syn.c: определения для синтаксического анализа и вычислений
#include "error.h"
#include "lex.h"
#include "syn.h"
double prim() { /* ... */ }
double term() { /* ... */ }
double expr() { /* ... */ }
Как обычно, определение основной программы тривиально:
// main.c: основная программа
#include <iostream.h>
#include "error.h"
#include "lex.h"
#include "syn.h"
#include "table.h"
int main(int argc, char* argv[]) { /* ... */ }
Какое число заголовочных файлов следует использовать для данной программы зависит от многих факторов. Большинство их определяется способом обработки файлов именно в вашей системе, а не собственно в С++. Например, если ваш редактор не может работать одновременно с несколькими файлами, диалоговая обработка нескольких заголовочных файлов затрудняется. Другой пример: может оказаться, что открытие и чтение 10 файлов по 50 строк каждый занимает существенно больше времени, чем открытие и чтение одного файла из 500 строк. В результате придется хорошенько подумать, прежде чем разбивать небольшую программу, используя множественные заголовочные файлы. Предостережение: обычно можно управиться с множеством, состоящим примерно из 10 заголовочных файлов (плюс стандартные заголовочные файлы). Если же вы будете разбивать программу на минимальные логические единицы с заголовочными файлами (например, создавая для каждой структуры свой заголовочный файл), то можете очень легко получить неуправляемое множество из сотен заголовочных файлов.
Модули
Программа С++ почти всегда состоит из нескольких раздельно транслируемых "модулей". Каждый "модуль" обычно называется исходным файлом, но иногда - единицей трансляции. Он состоит из последовательности описаний типов, функций, переменных и констант. Описание extern позволяет из одного исходного файла ссылаться на функцию или объект, определенные в другом исходном файле. Например:
extern "C" double sqrt ( double );
extern ostream cout;
Самый распространенный способ обеспечить согласованность описаний внешних во всех исходных файлах - поместить такие описания в специальные файлы, называемые заголовочными. Заголовочные файлы можно включать во все исходные файлы, в которых требуются описания внешних. Например, описание функции sqrt хранится в заголовочном файле стандартных математических функций с именем math.h, поэтому, если нужно извлечь квадратный корень из 4, можно написать:
#include <math.h>
//...
x = sqrt ( 4 );
Поскольку стандартные заголовочные файлы могут включаться во многие исходные файлы, в них нет описаний, дублирование которых могло бы вызвать ошибки. Так, тело функции присутствует в таких файлах, если только это функция-подстановка, а инициализаторы указаны только для констант ($$4.3). Не считая таких случаев, заголовочный файл обычно служит хранилищем для типов, он предоставляет интерфейс между раздельно транслируемыми частями программы.
В команде включения заключенное в угловые скобки имя файла (в нашем
примере - <math.h>) ссылается на файл, находящийся в стандартном каталоге включаемых файлов. Часто это - каталог /usr/include/CC. Файлы, находящиеся в других каталогах, обозначаются своими путевыми именами, взятыми в кавычки. Поэтому в следующих командах:
#include "math1.h"
#include "/usr/bs/math2.h"
включаются файл math1.h из текущего каталога пользователя и файл math2.h из каталога /usr/bs.
Приведем небольшой законченный пример, в котором строка определяется в одном файле, а печатается в другом. В файле header.h определяются нужные типы:
// header.h
extern char * prog_name;
extern void f();
Файл main.c является основной программой:
// main.c
#include "header.h"
char * prog_name = "примитивный, но законченный пример";
int main ()
{
f();
}
а строка печатается функцией из файла f.c:
// f.c
#include <stream.h>
#include "header.h"
void f ()
{
cout << prog_name << '\n';
}
При запуске транслятора С++ и передаче ему необходимых файлов-параметров в различных реализациях могут использоваться разные расширения имен для программ на С++. На машине автора трансляция и запуск программы выглядит так:
$ CC main.c f.c -o silly
$ silly
примитивный, но законченный пример
$
Кроме раздельной трансляции концепцию модульности в С++ поддерживают классы ($$5.4).
Модульное программирование
Со временем при в проектировании программ акцент сместился с организации процедур на организацию структур данных. Помимо всего прочего это вызвано и ростом размеров программ. Модулем обычно называют совокупность связанных процедур и тех данных, которыми они управляют. Парадигма программирования приобрела вид:
Определите, какие модули нужны; поделите программу так, чтобы данные были скрыты в этих модулях
Эта парадигма известна также как "принцип сокрытия данных". Если в языке нет возможности сгруппировать связанные процедуры вместе с данными, то он плохо поддерживает модульный стиль программирования. Теперь метод написания "хороших" процедур применяется для отдельных процедур модуля. Типичный пример модуля - определение стека. Здесь необходимо решить такие задачи:
[1] Предоставить пользователю интерфейс для стека (например, функции push () и pop ()).
[2] Гарантировать, что представление стека (например, в виде массива элементов) будет доступно лишь через интерфейс пользователя.
[3] Обеспечивать инициализацию стека перед первым его использованием.
Язык Модула-2 прямо поддерживает эту парадигму, тогда как С только допускает такой стиль. Ниже представлен на С возможный внешний интерфейс модуля, реализующего стек:
// описание интерфейса для модуля, реализующего стек символов:
void push ( char );
char pop ();
const int stack_size = 100;
Допустим, что описание интерфейса находится в файле stack.h, тогда реализацию стека можно определить следующим образом:
#include "stack.h" // используем интерфейс стека
static char v [ stack_size ]; // ``static'' означает локальный
// в данном файле/модуле
static char * p = v; // стек вначале пуст
void push ( char c )
{
//проверить на переполнение и поместить в стек
}
char pop ()
{
//проверить, не пуст ли стек, и считать из него
}
Вполне возможно, что реализация стека может измениться, например, если использовать для хранения связанный список. Пользователь в любом случае не имеет непосредственного доступа к реализации: v и p – статические переменные, т.е. переменные локальные в том модуле (файле), в котором они описаны. Использовать стек можно так:
#include "stack.h" // используем интерфейс стека
void some_function ()
{
push ( 'c' );
char c = pop ();
if ( c != 'c' ) error ( "невозможно" );
}
Поскольку данные есть единственная вещь, которую хотят скрывать, понятие упрятывания данных тривиально расширяется до понятия упрятывания информации, т.е. имен переменных, констант, функций и типов, которые тоже могут быть локальными в модуле. Хотя С++ и не предназначался специально для поддержки модульного программирования, классы поддерживают концепцию модульности ($$5.4.3 и $$5.4.4). Помимо этого С++, естественно, имеет уже продемонстрированные возможности модульности, которые есть в С, т.е. представление модуля как отдельной единицы трансляции.
Монитор экрана
Вначале было желание написать монитор экрана на С, чтобы еще больше подчеркнуть разделение между уровнями реализации. Но это оказалось утомительным, и поэтому выбрано компромиссное решение: стиль программирования, принятый в С (нет функций-членов, виртуальных функций, пользовательских операций и т.д.), но используются конструкторы, параметры функций полностью описываются и проверяются и т.д. Этот монитор очень напоминает программу на С, которую модифицировали, чтобы воспользоваться возможностями С++, но полностью переделывать не стали.
Экран представлен как двумерный массив символов и управляется функциями put_point() и put_line(). В них для связи с экраном используется структура point:
// файл screen.h
const int XMAX=40;
const int YMAX=24;
struct point {
int x, y;
point() { }
point(int a,int b) { x=; y=b; }
};
extern void put_point(int a, int b);
inline void put_point(point p) { put_point(p.x,p.y); }
extern void put_line(int, int, int, int);
extern void put_line(point a, point b)
{ put_line(a.x,a.y,b.x,b.y); }
extern void screen_init();
extern void screen_destroy();
extern void screen_refresh();
extern void screen_clear();
#include <iostream.h>
До вызова функций, выдающих изображение на экран (put_...), необходимо обратиться к функции инициализации экрана screen_init(). Изменения в структуре данных, описывающей экран, станут видимы на нем только после вызова функции обновления экрана screen_refresh(). Читатель может убедиться, что обновление экрана происходит просто с помощью копирования новых значений в массив, представляющий экран. Приведем функции и определения данных для управления экраном:
#include "screen.h"
#include <stream.h>
enum color { black='*', white=' ' };
char screen[XMAX] [YMAX];
void screen_init()
{
for (int y=0; y<YMAX; y++)
for (int x=0; x<XMAX; x++)
screen[x] [y] = white;
}
Функция
void screen_destroy() { }
приведена просто для полноты картины. В реальных системах обычно нужны подобные функции уничтожения объекта.
Точки записываются, только если они попадают на экран:
inline int on_screen(int a, int b) // проверка попадания
{
return 0<=a && a <XMAX && 0<=b && b<YMAX;
}
void put_point(int a, int b)
{
if (on_screen(a,b)) screen[a] [b] = black;
}
Для рисования прямых линий используется функция put_line():
void put_line(int x0, int y0, int x1, int y1)
/*
Нарисовать отрезок прямой (x0,y0) - (x1,y1).
Уравнение прямой: b(x-x0) + a(y-y0) = 0.
Минимизируется величина abs(eps),
где eps = 2*(b(x-x0)) + a(y-y0).
См. Newman, Sproull
``Principles of interactive Computer Graphics''
McGraw-Hill, New York, 1979. pp. 33-34.
*/
{
register int dx = 1;
int a = x1 - x0;
if (a < 0) dx = -1, a = -a;
register int dy = 1;
int b = y1 - y0;
if (b < 0) dy = -1, b = -b;
int two_a = 2*a;
int two_b = 2*b;
int xcrit = -b + two_a;
register int eps = 0;
for (;;) {
put_point(x0,y0);
if (x0==x1 && y0==y1) break;
if (eps <= xcrit) x0 +=dx, eps +=two_b;
if (eps>=a || a<b) y0 +=dy, eps -=two_a;
}
}
Имеются функции для очистки и обновления экрана:
void screen_clear() { screen_init(); }
void screen_refresh()
{
for (int y=YMAX-1; 0<=y; y--) { // с верхней строки до нижней
for (int x=0; x<XMAX; x++) // от левого столбца до правого
cout << screen[x] [y];
cout << '\n';
}
}
Но нужно понимать, что все эти определения хранятся в некоторой библиотеке как результат работы транслятора, и изменить их нельзя.
Небольшие объекты
Если в вашей программе много небольших объектов, размещаемых в свободной памяти, то может оказаться, что много времени тратится на размещение и удаление таких объектов. Для выхода из этой ситуации можно определить более оптимальный распределитель памяти общего назначения, а можно передать обязанность распределения свободной памяти создателю класса, который должен будет определить соответствующие функции размещения и удаления.
Вернемся к классу name, который использовался в примерах с table. Он мог бы определяться так:
struct name {
char* string;
name* next;
double value;
name(char*, double, name*);
~name();
void* operator new(size_t);
void operator delete(void*, size_t);
private:
enum { NALL = 128 };
static name* nfree;
};
Функции name::operator new() и name::operator delete() будут использоваться (неявно) вместо глобальных функций operator new() и operator delete(). Программист может для конкретного типа написать более эффективные по времени и памяти функции размещения и удаления, чем универсальные функции operator new() и operator delete(). Можно, например, разместить заранее "куски" памяти, достаточной для объектов типа name, и связать их в список; тогда операции размещения и удаления сводятся к простым операциям со списком. Переменная nfree используется как начало списка неиспользованных кусков памяти:
void* name::operator new(size_t)
{
register name* p = nfree; // сначала выделить
if (p)
nfree = p->next;
else { // выделить и связать в список
name* q = (name*) new char[NALL*sizeof(name) ];
for (p=nfree=&q[NALL-1]; q<p; p--) p->next = p-1;
(p+1)->next = 0;
}
return p;
}
Распределитель памяти, вызываемый new, хранит вместе с объектом его размер, чтобы операция delete выполнялась правильно. Этого дополнительного расхода памяти можно легко избежать, если использовать распределитель, рассчитанный на конкретный тип. Так, на машине автора функция name::operator new() для хранения объекта name использует 16 байтов, тогда как стандартная глобальная функция operator new() использует 20 байтов.
Отметим, что в самой функции name::operator new() память нельзя выделять таким простым способом:
name* q= new name[NALL];
Это вызовет бесконечную рекурсию, т.к. new будет вызывать name::name().
Освобождение памяти обычно тривиально:
void name::operator delete(void* p, size_t)
{
((name*)p)->next = nfree;
nfree = (name*) p;
}
Приведение параметра типа void* к типу name* необходимо, поскольку функция освобождения вызывается после уничтожения объекта, так что больше нет реального объекта типа name, а есть только кусок памяти размером sizeof(name). Параметры типа size_t в приведенных функциях name::operator new() и name::operator delete() не использовались. Как можно их использовать, будет показано в $$6.7. Отметим, что наши функции размещения и удаления используются только для объектов типа name, но не для массивов names.
Неявная передача операций
В примере из предыдущего раздела объекты Comparator на самом деле никак не использовались в вычислениях. Это просто "искусственные" параметры, нужные для правильного контроля типов. Введение таких параметров достаточно общий и полезный прием, хотя и не слишком красивый. Однако, если объект используется только для передачи операции (как и было в нашем случае), т.е. в вызываемой функции не используется ни значение, ни адрес объекта, то можно вместо этого передавать операцию неявно:
template<class T> void sort(Vector<T>& v)
{
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;
}
}
В результате мы приходим к первоначальному варианту использования sort():
void f(Vector<int>& vi,
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*>&);
}
Основное преимущество этого варианта, как и двух предыдущих, по сравнению с исходным вариантом в том, что часть программы, занятая собственно сортировкой, отделена от частей, в которых находятся такие операции, работающие с элементами, как, например lessthan. Необходимость подобного разделения растет с ростом программы, и особенный интерес это разделение представляет при проектировании библиотек. Здесь создатель библиотеки не может знать типы параметров шаблона, а пользователи не знают (или не хотят знать) специфику используемых в шаблоне алгоритмов. В частности, если бы в функции sort() использовался более сложный, оптимизированный и рассчитанный на коммерческое применение алгоритм, пользователь не очень бы стремился написать свою особую версию для типа char*, как это было сделано в $$8.4.1. Хотя реализация класса Comparator для специального случая char* тривиальна и может использоваться и в других ситуациях.
Неявное преобразование типа
В присваивании и выражении основные типы могут совершенно свободно использоваться совместно. Значения преобразовываются всюду, где это возможно, таким образом, чтобы информация не терялась. Точные правила преобразований даны в $$R.4 и $$R.5.4.
Все-таки есть ситуации, когда информация может быть потеряна или даже искажена. Потенциальным источником таких ситуаций становятся присваивания, в которых значение одного типа присваивается значению другого типа, причем в представлении последнего используется меньше разрядов. Допустим, что следующие присваивания выполняются на машине, в которой целые представляются в дополнительном коде, и символ занимает 8 разрядов:
int i1 = 256+255;
char ch = i1 // ch == 255
int i2 = ch; // i2 == ?
В присваивании ch=i1 теряется один разряд (и самый важный!), а когда
мы присваиваем значение переменной i2, у переменной ch значение "все единицы", т.е. 8 единичных разрядов. Но какое значение примет i2? На машине DEC VAX, в которой char представляет знаковые значения, это будет -1, а на машине Motorola 68K, в которой char - беззнаковый, это будет 255. В С++ нет динамических средств контроля подобных ситуаций, а контроль на этапе трансляции вообще слишком сложен, поэтому надо быть осторожными.
Неоднозначности
Присваивание или инициализация объекта класса X является законным, если присваиваемое значение имеет тип X, или если существует единственное преобразование его в значение типа X.
В некоторых случаях значение нужного типа строится с помощью повторных применений конструкторов или операций преобразования. Это должно задаваться явным образом, допустимо неявное пользовательское преобразование только одного уровня вложенности. В некоторых случаях существует несколько способов построения значения нужного типа, но это является незаконным. Приведем пример:
class x { /* ... */ x(int); x(char*); };
class y { /* ... */ y(int); };
class z { /* ... */ z(x); };
x f(x);
y f(y);
z g(z);
void k1()
{
f(1); // недопустимо, неоднозначность: f(x(1)) или f(y(1))
f(x(1));
f(y(1));
g("asdf"); // недопустимо, g(z(x("asdf"))) не используется
}
Пользовательские преобразования типа рассматриваются только в том случае, когда без них нельзя однозначно выбрать вызываемую функцию:
class x { /* ... */ x(int); };
void h(double);
void h(x);
void k2()
{
h(1);
}
Вызов h(1) можно интерпретировать либо как h(double(1)), либо как h(x(1)), поэтому в силу требования однозначности его можно счесть незаконным. Но поскольку в первой интерпретации используется только стандартное преобразование, то по правилам, указанным в $$4.6.6 и $$R.13.2, выбирается оно.
Правила на преобразования типа не слишком просто сформулировать и реализовать, не обладают они и достаточной общностью. Рассмотрим требование единственности законного преобразования. Проще всего разрешить транслятору применять любое преобразование, которое он сумеет найти. Тогда для выяснения корректности выражения не нужно рассматривать все существующие преобразования. К сожалению, в таком случае поведение программы будет зависеть от того, какое именно преобразование найдено. В результате поведение программы будет зависеть от порядка описаний преобразований. Поскольку часто эти описания разбросаны по разным исходным файлам (созданным, возможно, разными программистами), то результат программы будет зависеть в каком порядке эти файлы сливаются в программу. С другой стороны, можно вообще запретить неявные преобразования, и это самое простое решение. Но результатом будет некачественный интерфейс, определяемый пользователем, или взрывной рост перегруженных функций и операций, что мы и видели на примере класса complex из предыдущего раздела.
При самом общем подходе учитываются все сведения о типах и рассматриваются все существующие преобразования. Например, с учетом приведенных описаний в присваивании aa=f(1) можно разобраться с вызовом f(1), поскольку тип aa задает единственное преобразование. Если aa имеет тип x, то единственным преобразованием будет f(x(1)), поскольку только оно дает нужный для левой части тип x. Если aa имеет тип y, будет использоваться f(y(1)). При самом общем подходе удается разобраться и с вызовом g("asdf"), поскольку g(z(x("asdf))) является его единственной интерпретацией. Трудность этого подхода в том, что требуется доскональный разбор всего выражения, чтобы установить интерпретацию каждой операции и вызова функции. В результате трансляция замедляется, вычисление выражения может произойти странным образом и появляются загадочные сообщения об ошибках, когда транслятор учитывает определенные в библиотеках преобразования и т.д. В результате транслятору приходится учитывать больше информации, чем известно самому программисту! Выбран подход, при котором проверка является строго восходящим процессом, когда в каждый момент рассматривается только одна операция с операндами, типы которых уже прошли проверку.
Требование строго восходящего разбора выражения предполагает, что тип возвращаемого значения не учитывается при разрешении перегрузки:
class quad {
// ...
public:
quad(double);
// ...
};
quad operator+(quad,quad);
void f(double a1, double a2)
{
quad r1 = a1+a2; // сложение с двойной точностью
quad r2 = quad(a1)+a2; // вынуждает использовать
// операции с типами quad
}
В проектировании языка делался расчет на строго восходящий разбор, поскольку он более понятный, а кроме того, не дело транслятора решать такие вопросы, какую точность для сложения желает программист.
Однако, надо отметить, что если определились типы обеих частей в присваивании и инициализации, то для их разрешения используется они оба:
class real {
// ...
public:
operator double();
operator int();
// ...
};
void g(real a)
{
double d = a; // d = a.double();
int i = a; // i = a.int();
d = a; // d = a.double();
i = a; // i = a.int();
}
В этом примере выражения все равно разбираются строго восходящим методом, когда в каждый момент рассматриваются только одна операция и типы ее операндов.
Неопределенное число параметров
Существуют функции, в описании которых невозможно указать число и типы всех допустимых параметров. Тогда список формальных параметров завершается эллипсисом (...), что означает: "и, возможно, еще несколько аргументов". Например:
int printf(const char* ...);
При вызове printf обязательно должен быть указан параметр типа char*, однако могут быть (а могут и не быть) еще другие параметры. Например:
printf("Hello, world\n");
printf("My name is %s %s\n", first_name, second_name);
printf("%d + %d = %d\n", 2,3,5);
Такие функции пользуются для распознавания своих фактических параметров недоступной транслятору информацией. В случае функции printf первый параметр является строкой, специфицирующей формат вывода. Она может содержать специальные символы, которые позволяют правильно воспринять последующие параметры. Например, %s означает -"будет фактический параметр типа char*", %d означает -"будет фактический параметр типа int" (см. $$10.6). Но транслятор этого не знает, и поэтому он не может убедиться, что объявленные параметры действительно присутствуют в вызове и имеют соответствующие типы. Например, следующий вызов
printf("My name is %s %s\n",2);
нормально транслируется, но приведет (в лучшем случае) к неожиданной выдаче. Можете проверить сами.
Очевидно, что раз параметр неописан, то транслятор не имеет сведений для контроля и стандартных преобразований типа этого параметра. Поэтому char или short передаются как int, а float как double, хотя пользователь, возможно, имел в виду другое.
В хорошо продуманной программе может потребоваться, в виде исключения, лишь несколько функций, в которых указаны не все типы параметров. Чтобы обойти контроль типов параметров, лучше использовать перегрузку функций или стандартные значения параметров, чем параметры, типы которых не были описаны. Эллипсис становится необходимым только тогда, когда могут меняться не только типы, но и число параметров. Чаще всего эллипсис используется для определения интерфейса с библиотекой стандартных функций на С, если этим функциям нет замены:
extern "C" int fprintf(FILE*, const char* ...);
extern "C" int execl(const char* ...);
Есть стандартный набор макроопределений, находящийся в <stdarg.h>, для выбора незаданных параметров этих функций. Рассмотрим функцию реакции на ошибку, первый параметр которой показывает степень тяжести ошибки. За ним может следовать произвольное число строк. Нужно составить сообщение об ошибке с учетом, что каждое слово из него передается как отдельная строка:
extern void error(int ...)
extern char* itoa(int);
main(int argc, char* argv[])
{
switch (argc) {
case 1:
error(0,argv[0],(char*)0);
break;
case 2:
error(0,argv[0],argv[1],(char*)0);
break;
default:
error(1,argv[0],
"With",itoa(argc-1),"arguments",(char*)0);
}
// ...
}
Функция itoa возвращает строку символов, представляющую ее целый параметр. Функцию реакции на ошибку можно определить так:
#include <stdarg.h>
void error(int severity ...)
/*
за "severity" (степень тяжести ошибки) следует
список строк, завершающийся нулем
*/
{
va_list ap;
va_start(ap,severity); // начало параметров
for (;;) {
char* p = va_arg(ap,char*);
if (p == 0) break;
cerr << p << ' ';
}
va_end(ap); // очистка параметров
cerr << '\n';
if (severity) exit(severity);
}
Вначале при вызове va_start() определяется и инициализируется va_list. Параметрами макроопределения va_start являются имя типа va_list и последний формальный параметр. Для выборки по порядку неописанных параметров используется макроопределение va_arg(). В каждом обращении к va_arg нужно задавать тип ожидаемого фактического параметра. В va_arg() предполагается, что параметр такого типа присутствует в вызове, но обычно нет возможности проверить это. Перед выходом из функции, в которой было обращение к va_start, необходимо вызвать va_end. Причина в том, что в va_start() могут быть такие операции со стеком, из-за которых корректный возврат из функции становится невозможным. В va_end() устраняются все нежелательные изменения стека.
Приведение 0 к (char*)0 необходимо потому, что sizeof(int) не обязано совпадать с sizeof(char*). Этот пример демонстрирует все те сложности, с которыми приходится сталкиваться программисту, если он решил обойти контроль типов, используя эллипсис.
Неожиданные особые ситуации
Если к описанию особых ситуаций относиться не достаточно серьезно, то результатом может быть вызов 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)();
PFV set_unexpected(PFV);
class STC { // класс для сохранения и восстановления
PFV old; // функций unexpected()
public:
STC(PFV f) { old = set_unexpected(f); }
~STC() { set_unexpected(old); }
};
Теперь мы определим функцию, которая должна в нашем примере заменить unexpected():
void rethrow() { throw; } // перезапуск всех сетевых
// особых ситуаций
Наконец, можно дать вариант функции g(), предназначенный для работы в сетевом режиме:
void networked_g()
{
STC xx(&rethrow); // теперь unexpected() вызывает rethrow()
g();
}
В предыдущем разделе было показано, что unexpected() потенциально вызывается из обработчика catch (...). Значит в нашем случае обязательно произойдет повторный запуск особой ситуации. Повторный запуск, когда особая ситуация не запускалась, приводит к вызову terminate(). Поскольку обработчик catch (...) находится вне той области видимости, в которой была запущена сетевая особая ситуация, бесконечный цикл возникнуть не может.
Есть еще одно, довольно опасное, решение, когда на неожиданную особую ситуацию просто "закрывают глаза":
void muddle_on() { cerr << "не замечаем особой ситуации\n"; }
// ...
STC xx(&muddle_on); // теперь действие unexpected() сводится
// просто к печати сообщения
Такое переопределение действия unexpected() позволяет нормально вернуться из функции, обнаружившей неожиданную особую ситуацию. Несмотря на свою очевидную опасность, это решение используется. Например, можно "закрыть глаза" на особые ситуации в одной части системы и отлаживать другие ее части. Такой подход может быть полезен в процессе отладки и развития системы, перенесенной с языка программирования без особых ситуаций. Все-таки, как правило лучше, если ошибки проявляются как можно раньше.
Возможно другое решение, когда вызов unexpected() преобразуется в запуск особой ситуации Fail (неудача):
void fail() { throw Fail; }
// ...
STC yy(&fail);
При таком решении вызывающая функция не должна подробно разбираться в возможном результате вызываемой функции: эта функции завершится либо успешно (т.е. возвратится нормально), либо неудачно (т.е. запустит Fail). Очевидный недостаток этого решения в том, что не учитывается дополнительная информация, которая может сопровождать особую ситуацию. Впрочем, при необходимости ее можно учесть, если передавать информацию вместе с Fail.
Неперехваченные особые ситуации
Если особая ситуация запущена и не перехвачена, то вызывается функция 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(). Она возвращает значение, которое показывает окружающей системе насколько корректно закончилась программа.
Несколько полезных советов
Ниже представлен "свод правил", который стоит учитывать при изучении С++. Когда вы станете более опытными, то на базе этих правил сможете сформулировать свои собственные, которые будут более подходить для ваших задач и более соответствовать вашему стилю программирования. Сознательно выбраны очень простые правила, и в них опущены подробности. Не следует воспринимать их слишком буквально. Хорошая программа требует и ума, и вкуса, и терпения. С первого раза обычно она не получается, поэтому экспериментируйте! Итак, свод правил.
[1] Когда вы пишите программу, то создаете конкретные представления тех понятий, которые использовались в решении поставленной задачи. Структура программы должна отражать эти понятия настолько явно, насколько это возможно.
[a] Если вы считаете "нечто" отдельным понятием, то сделайте его классом.
[b] Если вы считаете "нечто" существующим независимо, то сделайте его объектом некоторого класса.
[c] Если два класса имеют нечто существенное, и оно является для них общим, то выразите эту общность с помощью базового класса.
[d] Если класс является контейнером некоторых объектов, сделайте его шаблонным классом.
[2] Если определяется класс, который не реализует математических объектов вроде матриц или комплексных чисел и не является типом низкого уровня наподобие связанного списка, то:
[а] Не используйте глобальных данных.
[b] Не используйте глобальных функций (не членов).
[c] Не используйте общих данных-членов.
[d] Не используйте функции friend (но только для того, чтобы избежать [а], [b] или [c]).
[e] Не обращайтесь к данным-членам другого объекта непосредственно.
[f] Не заводите в классе "поле типа"; используйте виртуальные функции.
[g] Используйте функции-подстановки только как средство значительной оптимизации.
Нуль
Нуль (0) имеет тип int. Благодаря стандартным преобразованиям ($$R.4) 0 можно использовать как константу целого типа, или типа с плавающей точкой, или типа указателя. Нельзя разместить никакой объект, если вместо адреса указан 0. Какой из типов нуля использовать, определяется контекстом. Обычно (но необязательно) нуль представляется последовательностью разрядов "все нули" подходящей длины.
Об авторе книги:
Бьерн Страуструп является разработчиком языка С++ и создателем первого транслятора. Он - сотрудник научно-исследовательского вычислительного центра AT&T Bell Laboratories в Мюррей Хилл (Нью-Джерси, США). Он получил звание магистра математики и вычислительной техники в университете г. Аарус (Дания), а докторское звание по вычислительной технике в кэмбриджском университете (Англия). Он специализируется в области распределенных систем, операционных систем, моделирования и программирования. Вместе с М. А. Эллис он является автором полного руководства по языку С++ - "Руководство по С++ с примечаниями".
Объединения
Рассмотрим таблицу имен, в которой каждый элемент содержит имя и его значение. Значение может задаваться либо строкой, либо целым числом:
struct entry {
char* name;
char type;
char* string_value; // используется если type == 's'
int int_value; // используется если type == 'i'
};
void print_entry(entry* p)
{
switch(p->type) {
case 's':
cout << p->string_value;
break;
case 'i':
cout << p->int_value;
break;
default:
cerr << "type corrupted\n";
break;
}
}
Поскольку переменные string_value и int_value никогда не могут использоваться одновременно, очевидно, что часть памяти пропадает впустую. Это можно легко исправить, описав обе переменные как члены объединения, например, так:
struct entry {
char* name;
char type;
union {
char* string_value; // используется если type == 's'
int int_value; // используется если type == 'i'
};
};
Теперь гарантируется, что при выделении памяти для entry члены string_value и int_value будут размещаться с одного адреса, и при этом не нужно менять все части программы, работающие с entry. Из этого следует, что все члены объединения вместе занимают такой же объем памяти, какой занимает наибольший член объединения.
Надежный способ работы с объединением заключается в том, чтобы выбирать значение с помощью того же самого члена, который его записывал. Однако, в больших программах трудно гарантировать, что объединение используется только таким способом, а в результате использования не того члена обЪединения могут возникать трудно обнаруживаемые ошибки. Но можно встроить объединение в такую структуру, которая обеспечит правильную связь между значением поля типа и текущим типом члена объединения ($$5.4.6).
Иногда объединения используют для "псевдо-преобразований" типа (в основном на это идут программисты, привыкшие к языкам, в которых нет средств преобразования типов, и в результате приходится обманывать транслятор). Приведем пример такого "преобразования" int в int* на машине VAX, которое достигается простым совпадением разрядов:
struct fudge {
union {
int i;
int* p;
};
};
fudge a;
a.i = 4095;
int* p = a.p; // некорректное использование
В действительности это вовсе не преобразование типа, т.к. на одних машинах int и int* занимают разный объем памяти, а на других целое не может размещаться по адресу, задаваемому нечетным числом. Такое использование объединений не является переносимым, тогда как существует переносимый способ задания явного преобразования типа ($$3.2.5).
Иногда объединения используют специально, чтобы избежать преобразования типов. Например, можно использовать fudge, чтобы узнать, как представляется указатель 0:
fudge.p = 0;
int i = fudge.i; // i необязательно должно быть 0
Объединению можно дать имя, то есть можно сделать его полноправным типом. Например, fudge можно описать так:
union fudge {
int i;
int* p;
};
и использовать (некорректно) точно так же, как и раньше. Вместе с тем,
поименованные объединения можно использовать и вполне корректным и оправданным способом (см. $$5.4.6).
Объектно-ориентированное программирование
Проблема состоит в том, что мы не различаем общие свойства фигур (например, фигура имеет цвет, ее можно нарисовать и т.д.) и свойства конкретной фигуры (например, окружность - это такая фигура, которая имеет радиус, она изображается с помощью функции, рисующей дуги и т.д.). Суть объектно-ориентированного программирования в том, что оно позволяет выражать эти различия и использует их. Язык, который имеет конструкции для выражения и использования подобных различий, поддерживает объектно-ориентированное программирование. Все другие языки не поддерживают его. Здесь основную роль играет механизм наследования, заимствованный из языка Симула. Вначале определим класс, задающий общие свойства всех фигур:
class shape
{
point center;
color col;
// ...
public:
point where () { return center; }
void move ( point to ) { center = to; draw(); }
virtual void draw ();
virtual void rotate ( int );
// ...
};
Те функции, для которых можно определить заявленный интерфейс, но реализация которых (т.е. тело с операторной частью) возможна только для конкретных фигур, отмечены служебным словом virtual (виртуальные). В Симуле и С++ виртуальность функции означает: "функция может быть определена позднее в классе, производном от данного". С учетом такого определения класса можно написать общие функции, работающие с фигурами:
void rotate_all ( shape v [], int size, int angle )
// повернуть все элементы массива "v" размера "size"
// на угол равный "angle"
{
int i = 0;
while ( i<size )
{
v [ i ] . rotate ( angle );
i = i + 1;
}
}
Для определения конкретной фигуры следует указать, прежде всего, что это - именно фигура и задать ее особые свойства (включая и виртуальные функции):
class circle : public shape
{
int radius;
public:
void draw () { /* ... */ };
void rotate ( int ) {} // да, пока пустая функция
};
В языке С++ класс circle называется производным по отношению к классу
shape, а класс shape называется базовым для класса circle. Возможна другая терминология, использующая названия "подкласс" и "суперкласс" для классов circle и shape соответственно. Теперь парадигма программирования формулируется так:
Определите, какой класс вам необходим; предоставьте полный набор операций для каждого класса; общность классов выразите явно с помощью наследования.
Если общность между классами отсутствует, вполне достаточно абстракции
данных. Насколько применимо объектно-ориентированное программирование для данной области приложения определяется степенью общности между разными типами, которая позволяет использовать наследование и виртуальные функции. В некоторых областях, таких, например, как интерактивная графика, есть широкий простор для объектно-ориентированного программирования. В других областях, в которых используются традиционные арифметические типы и вычисления над ними, трудно найти применение для более развитых стилей программирования, чем абстракция данных. Здесь средства, поддерживающие объектно-ориентированное программирование, очевидно, избыточны.
Нахождение общности среди отдельных типов системы представляет собой нетривиальный процесс. Степень такой общности зависит от способа проектирования системы. В процессе проектирования выявление общности классов должно быть постоянной целью. Она достигается двумя способами: либо проектированием специальных классов, используемых как "кирпичи" при построении других, либо поиском похожих классов для выделения их общей части в один базовый класс.
С попытками объяснить, что такое объектно-ориентированное программирование, не используя конкретных конструкций языков программирования, можно познакомиться в работах [2] и [6], приведенных в списке литературы в главе 11.
Итак, мы указали, какую минимальную поддержку должен обеспечивать язык программирования для процедурного программирования, для упрятывания данных, абстракции данных и объектно-ориентированного программирования. Теперь несколько подробнее опишем средства языка, хотя и не самые существенные, но позволяющие более эффективно реализовать абстракцию данных и объектно-ориентированное программирование.
Объекты и адреса
Можно выделять память для "переменных", не имеющих имен, и использовать эти переменные. Возможно даже присваивание таким странно выглядящим "переменным", например, *p[a+10]=7. Следовательно, есть потребность именовать "нечто хранящееся в памяти". Можно привести подходящую цитату из справочного руководства: "Любой объект - это некоторая область памяти, а адресом называется выражение, ссылающееся на объект или функцию" ($$R.3.7). Слову адрес (lvalue - left value, т.е. величина слева) первоначально приписывался смысл "нечто, что может в присваивании стоять слева". Адрес может ссылаться и на константу (см. $$2.5). Адрес, который не был описан со спецификацией const, называется изменяемым адресом.
Объекты класса как члены
Рассмотрим пример:
class classdef {
table members;
int no_of_members;
// ...
classdef(int size);
~classdef();
};
Цель этого определения, очевидно, в том, чтобы classdef содержал член, являющийся таблицей размером size, но есть сложность: надо обеспечить вызов конструктора table::table() с параметром size. Это можно сделать, например, так:
classdef::classdef(int size)
:members(size)
{
no_of_members = size;
// ...
}
Параметр для конструктора члена (т.е. для table::table()) указывается в определении (но не в описании) конструктора класса, содержащего член (т.е. в определении classdef::classdef()). Конструктор для члена будет вызываться до выполнения тела того конструктора, который задает для него список параметров.
Аналогично можно задать параметры для конструкторов других членов (если есть еще другие члены):
class classdef {
table members;
table friends;
int no_of_members;
// ...
classdef(int size);
~classdef();
};
Списки параметров для членов отделяются друг от друга запятыми (а не двоеточиями), а список инициализаторов для членов можно задавать в произвольном порядке:
classdef::classdef(int size)
: friends(size), members(size), no_of_members(size)
{
// ...
}
Конструкторы вызываются в том порядке, в котором они заданы в описании класса.
Подобные описания конструкторов существенны для типов, инициализация и присваивание которых отличны друг от друга, иными словами, для объектов, являющихся членами класса с конструктором, для постоянных членов или для членов типа ссылки. Однако, как показывает член no_of_members из приведенного примера, такие описания конструкторов можно использовать для членов любого типа.
Если конструктору члена не требуется параметров, то и не нужно задавать никаких списков параметров. Так, поскольку конструктор table::table() был определен со стандартным значением параметра, равным 15, достаточно такого определения:
classdef::classdef(int size)
: members(size), no_of_members(size)
{
// ...
}
Тогда размер таблицы friends будет равен 15.
Если уничтожается объект класса, который сам содержит объекты класса (например, classdef), то вначале выполняется тело деструктора объемлющего класса, а затем деструкторы членов в порядке, обратном их описанию.
Рассмотрим вместо вхождения объектов класса в качестве членов традиционное альтернативное ему решение: иметь в классе указатели на члены и инициализировать члены в конструкторе:
class classdef {
table* members;
table* friends;
int no_of_members;
// ...
};
classdef::classdef(int size)
{
members = new table(size);
friends = new table; // используется стандартный
// размер table
no_of_members = size;
// ...
}
Поскольку таблицы создавались с помощью операции new, они должны уничтожаться операцией delete:
classdef::~classdef()
{
// ...
delete members;
delete friends;
}
Такие отдельно создаваемые объекты могут оказаться полезными, но учтите, что members и friends указывают на независимые от них объекты, каждый из которых надо явно размещать и удалять. Кроме того, указатель и объект в свободной памяти суммарно занимают больше места, чем объект-член.
Область видимости
Описанием определяется область видимости имени. Это значит, что имя может использоваться только в определенной части текста программы. Если имя описано в функции (обычно его называют "локальным именем"), то область видимости имени простирается от точки описания до конца блока, в котором появилось это описание. Если имя не находится в описании функции или класса (его обычно называют "глобальным именем"), то область видимости простирается от точки описания до конца файла, в котором появилось это описание. Описание имени в блоке может скрывать описание в объемлющем блоке или глобальное имя; т.е. имя может быть переопределено так, что оно будет обозначать другой объект внутри блока. После выхода из блока прежнее значение имени (если оно было) восстанавливается. Приведем пример:
int x; // глобальное x
void f()
{
int x; // локальное x скрывает глобальное x
x = 1; // присвоить локальному x
{
int x; // скрывает первое локальное x
x = 2; // присвоить второму локальному x
}
x = 3; // присвоить первому локальному x
}
int* p = &x; // взять адрес глобального x
В больших программах не избежать переопределения имен. К сожалению,
человек легко может проглядеть такое переопределение. Возникающие из-за этого ошибки найти непросто, возможно потому, что они достаточно редки. Следовательно, переопределение имен следует свести к минимуму. Если вы обозначаете глобальные переменные или локальные переменные в большой функции такими именами, как i или x, то сами напрашиваетесь на неприятности. Есть возможность с помощью операции разрешения области видимости :: обратиться к скрытому глобальному имени, например:
int x;
void f2()
{
int x = 1; // скрывает глобальное x
::x = 2; // присваивание глобальному x
}
Возможность использовать скрытое локальное имя отсутствует.
Область видимости имени начинается в точке его описания (по окончании описателя, но еще до начала инициализатора - см. $$R.3.2). Это означает, что имя можно использовать даже до того, как задано его начальное значение. Например:
int x;
void f3()
{
int x = x; // ошибочное присваивание
}
Такое присваивание недопустимо и лишено смысла. Если вы попытаетесь транслировать эту программу, то получите предупреждение: "использование до задания значения". Вместе с тем, не применяя оператора ::, можно использовать одно и то же имя для обозначения двух различных объектов блока. Например:
int x = 11;
void f4() // извращенный пример
{
int y = x; // глобальное x
int x = 22;
y = x; // локальное x
}
Переменная y инициализируется значением глобального x, т.е. 11, а затем ей присваивается значение локальной переменной x, т.е. 22. Имена формальных параметров функции считаются описанными в самом большом блоке функции, поэтому в описании ниже есть ошибка:
void f5(int x)
{
int x; // ошибка
}
Здесь x определено дважды в одной и той же области видимости. Это хотя и не слишком редкая, но довольно тонкая ошибка.
Обработка ошибок
Поскольку программа достаточно проста, не надо особо беспокоиться об обработке ошибок. Функция error просто подсчитывает число ошибок, выдает сообщение о них и возвращает управление обратно:
int no_of_errors;
double error(const char* s)
{
cerr << "error: " << s << "\n";
no_of_errors++;
return 1;
}
Небуферизованный выходной поток cerr обычно используется именно для выдачи сообщений об ошибках. Управление возвращается из error() потому, что ошибки, как правило, встречаются посреди вычисления выражения. Значит надо либо полностью прекращать вычисления, либо возвращать значение, которое не должно вызвать последующих ошибок. Для простого калькулятора больше подходит последнее. Если бы функция get_token() отслеживала номера строк, то функция error() могла бы указывать пользователю приблизительное место ошибки. Это было бы полезно при неинтерактивной работе с калькулятором. Часто после появления ошибки программа должна завершиться, поскольку не удалось предложить разумный вариант ее дальнейшего выполнения. Завершить ее можно с помощью вызова функции exit(), которая заканчивает работу с выходными потоками ($$10.5.1) и завершает программу, возвращая свой параметр в качестве ее результата. Более радикальный способ завершения программы - это вызов функции abort(), которая прерывает выполнение программы немедленно или сразу же после сохранения информации для отладчика (сброс оперативной памяти). Подробности вы можете найти в своем справочном руководстве.
Более тонкие приемы обработки ошибок можно предложить, если ориентироваться на особые ситуации (см.$$9), но предложенное решение вполне приемлемо для игрушечного калькулятора в 200 строк.
// вызов do_something() приведет к вызову Vector::operator[]()
// из-за недопустимого значения индекса
}
// ...
}
Обработчиком особой ситуации называется конструкция
catch ( /* ... */ ) {
// ...
}
Ее можно использовать только сразу после блока, начинающегося служебным
словом try, или сразу после другого обработчика особой ситуации. Служебным является и слово catch. После него идет в скобках описание, которое используется аналогично описанию формальных параметров функции, а именно, в нем задается тип объектов, на которые рассчитан обработчик, и, возможно, имена параметров (см. $$9.3). Если в do_something() или в любой вызванной из нее функции произойдет ошибка индекса (на любом объекте Vector), то обработчик перехватит особую ситуацию и будет выполняться часть, обрабатывающая ошибку. Например, определения следующих функций приведут к запуску обработчика в f():
void do_something()
{
// ...
crash(v);
// ...
}
void crash(Vector& v)
{
v[v.size()+10]; // искусственно вызываем ошибку индекса
}
Процесс запуска и перехвата особой ситуации предполагает просмотр цепочки вызовов от точки запуска особой ситуации до функции, в которой она перехватывается. При этом восстанавливается состояние стека, соответствующее функции, перехватившей ошибку, и при проходе по всей цепочке вызовов для локальных объектов функций из этой цепочки вызываются деструкторы. Подробно это описано в $$9.4.
Если при просмотре всей цепочки вызовов, начиная с запустившей особую ситуацию функции, не обнаружится подходящий обработчик, то программа завершается. Подробно это описано в $$9.7.
Если обработчик перехватил особую ситуацию, то она будет обрабатываться
и другие, рассчитанные на эту ситуацию, обработчики не будут рассматриваться. Иными словами, активирован будет только тот обработчик, который находится в самой последней вызывавшейся функции, содержащей соответствующие обработчики. В нашем примере функция f() перехватит Vector::Range, поэтому эту особую ситуацию нельзя перехватить ни в какой вызывающей f() функции:
int ff(Vector& v)
{
try {
f(v); // в f() будет перехвачена Vector::Range
}
catch (Vector::Range) { // значит сюда мы никогда не попадем
// ...
}
}
Обработка особых ситуаций
По мере роста программ, а особенно при активном использовании библиотек появляется необходимость стандартной обработки ошибок (или, в более широком смысле, "особых ситуаций"). Языки Ада, Алгол-68 и Clu поддерживают стандартный способ обработки особых ситуаций.
Снова вернемся к классу vector. Что нужно делать, когда операции индексации передано значение индекса, выходящее за границы массива? Создатель класса vector не знает, на что рассчитывает пользователь в таком случае, а пользователь не может обнаружить подобную ошибку (если бы мог, то эта ошибка вообще не возникла бы). Выход такой: создатель класса обнаруживает ошибку выхода за границу массива, но только сообщает о ней неизвестному пользователю. Пользователь сам принимает необходимые меры.
Например:
class vector {
// определение типа возможных особых ситуаций
class range { };
// ...
};
Вместо вызова функции ошибки в функции vector::operator[]() можно перейти на ту часть программы, в которой обрабатываются особые ситуации. Это называется "запустить особую ситуацию" ("throw the exception"):
int & vector::operator [] ( int i )
{
if ( i < 0 || sz <= i ) throw range ();
return v [ i ];
}
В результате из стека будет выбираться информация, помещаемая туда при
вызовах функций, до тех пор, пока не будет обнаружен обработчик особой ситуации с типом range для класса вектор (vector::range); он и будет выполняться.
Обработчик особых ситуаций можно определить только для специального блока:
void f ( int i )
{
try
{
// в этом блоке обрабатываются особые ситуации
// с помощью определенного ниже обработчика
vector v ( i );
// ...
v [ i + 1 ] = 7; // приводит к особой ситуации range
// ...
g (); // может привести к особой ситуации range
// на некоторых векторах
}
catch ( vector::range )
{
error ( "f (): vector range error" );
return;
}
}
Использование особых ситуаций делает обработку ошибок более упорядоченной и понятной. Обсуждение и подробности отложим до главы 9.
Обширный интерфейс
Когда обсуждались абстрактные типы ($$13.3) и узловые классы ($$13.4), было подчеркнуто, что все функции базового класса реализуются в самом базовом или в производном классе. Но существует и другой способ построения классов. Рассмотрим, например, списки, массивы, ассоциативные массивы, деревья и т.д. Естественно желание для всех этих типов, часто называемых контейнерами, создать обобщающий их класс, который можно использовать в качестве интерфейса с любым из перечисленных типов. Очевидно, что пользователь не должен знать детали, касающиеся конкретного контейнера. Но задача определения интерфейса для обобщенного контейнера нетривиальна. Предположим, что такой контейнер будет определен как абстрактный тип, тогда какие операции он должен предоставлять? Можно предоставить только те операции, которые есть в каждом контейнере, т.е. пересечение множеств операций, но такой интерфейс будет слишком узким. На самом деле, во многих, имеющих смысл случаях такое пересечение пусто. В качестве альтернативного решения можно предоставить объединение всех множеств операций и предусмотреть динамическую ошибку, когда в этом интерфейсе к объекту применяется "несуществующая" операция. Объединение интерфейсов классов, представляющих множество понятий, называется обширным интерфейсом. Опишем "общий" контейнер объектов типа T:
class container {
public:
struct Bad_operation { // класс особых ситуаций
const char* p;
Bad_operation(const char* pp) : p(pp) { }
};
virtual void put(const T*)
{ throw Bad_operation("container::put"); }
virtual T* get()
{ throw Bad_operation("container::get"); }
virtual T*& operator[](int)
{ throw Bad_operation("container::[](int)"); }
virtual T*& operator[](const char*)
{ throw Bad_operation("container::[](char*)"); }
// ...
};
Все-таки существует мало реализаций, где удачно представлены как индексирование, так и операции типа списочных, и, возможно, не стоит совмещать их в одном классе.
Отметим такое различие: для гарантии проверки на этапе трансляции в абстрактном типе используются чистые виртуальные функции, а для обнаружения ошибок на этапе выполнения используются функции обширного интерфейса, запускающие особые ситуации.
Можно следующим образом описать контейнер, реализованный как простой список с односторонней связью:
class slist_container : public container, private slist {
public:
void put(const T*);
T* get();
T*& operator[](int)
{ throw Bad_operation("slist::[](int)"); }
T*& operator[](const* char)
{ throw Bad_operation("slist::[](char*)"); }
// ...
};
Чтобы упростить обработку динамических ошибок для списка введены операции индексирования. Можно было не вводить эти нереализованные для списка операции и ограничиться менее полной информацией, которую предоставляют особые ситуации, запущенные в классе container:
class vector_container : public container, private vector {
public:
T*& operator[](int);
T*& operator[](const char*);
// ...
};
Если быть осторожным, то все работает нормально:
void f()
{
slist_container sc;
vector_container vc;
// ...
}
void user(container& c1, container& c2)
{
T* p1 = c1.get();
T* p2 = c2[3];
// нельзя использовать c2.get() или c1[3]
// ...
}
Все же для избежания ошибок при выполнении программы часто приходится использовать динамическую информацию о типе ($$13.5) или особые ситуации ($$9). Приведем пример:
void user2(container& c1, container& c2)
/*
обнаружение ошибки просто, восстановление - трудная задача
*/
{
try {
T* p1 = c1.get();
T* p2 = c2[3];
// ...
}
catch(container::Bad_operation& bad) {
// Приехали!
// А что теперь делать?
}
}
или другой пример:
void user3(container& c1, container& c2)
/*
обнаружение ошибки непросто,
а восстановление по прежнему трудная задача
*/
{
slist* sl = ptr_cast(slist_container,&c1);
vector* v = ptr_cast(vector_container, &c2);
if (sl && v) {
T* p1 = c1.get();
T* p2 = c2[3];
// ...
}
else {
// Приехали!
// А что теперь делать?
}
}
Оба способа обнаружения ошибки, показанные на этих примерах, приводят к программе с "раздутым" кодом и низкой скоростью выполнения. Поэтому обычно просто игнорируют возможные ошибки в надежде, что пользователь на них не натолкнется. Но задача от этого не упрощается, ведь полное тестирование затруднительно и требует многих усилий.
Поэтому, если целью является программа с хорошими характеристиками, или требуются высокие гарантии корректности программы, или, вообще, есть хорошая альтернатива, лучше не использовать обширные интерфейсы. Кроме того, использование обширного интерфейса нарушает взаимнооднозначное соответствие между классами и понятиями, и тогда начинают вводить новые производные классы просто для удобства реализации.
Операции преобразования
Конструктор удобно использовать для преобразования типа, но возможны нежелательные последствия:
[1] Неявные преобразования от пользовательского типа к основному невозможны (поскольку основные типы не являются классами).
[2] Нельзя задать преобразование из нового типа в старый, не изменяя описания старого типа.
[3] Нельзя определить конструктор с одним параметром, не определив тем самым и преобразование типа.
Последнее не является большой проблемой, а первые две можно преодолеть, если определить операторную функцию преобразования для исходного типа. Функция-член X::operator T(), где T – имя типа, определяет преобразование типа X в T. Например, можно определить тип tiny (крошечный), значения которого находятся в диапазоне 0..63, и этот тип может в арифметических операциях практически свободно смешиваться с целыми:
class tiny {
char v;
void assign(int i)
{ if (i>63) { error("выход из диапазона"); v=i&~63; }
v=i;
}
public:
tiny(int i) { assign(i) }
tiny(const tiny& t) { v = t.v; }
tiny& operator=(const tiny& t) { v = t.v; return *this; }
tiny& operator=(int i) { assign(i); return *this; }
operator int() { return v; }
};
Попадание в диапазон проверяется как при инициализации объекта tiny, так и в присваивании ему int. Один объект tiny можно присвоить другому без контроля диапазона. Для выполнения обычных операций с целыми для переменных типа tiny определяется функция tiny::operator int(), производящая неявное преобразование типа из tiny в int. Там, где требуется int, а задана переменная типа tiny, используется преобразованное к int значение:
void main()
{
tiny c1 = 2;
tiny c2 = 62;
tiny c3 = c2 -c1; // c3 = 60
tiny c4 = c3; // контроля диапазона нет (он не нужен)
int i = c1 + c2; // i = 64
c1 = c2 + 2 * c1; // выход из диапазона: c1 = 0 (а не 66)
c2 = c1 - i; // выход из диапазона: c2 = 0
c3 = c2; // контроля диапазона нет (он не нужен)
}
Более полезным может оказаться вектор из объектов tiny, поскольку он позволяет экономить память. Чтобы такой тип было удобно использовать, можно воспользоваться операцией индексации [].
Пользовательские операции преобразования типа могут пригодиться для работы с типами, реализующими нестандартные представления чисел (арифметика с основанием 100, арифметика чисел с фиксированной точкой, представление в двоично-десятичной записи и т.д.). При этом обычно приходится переопределять такие операции, как + и *.
Особенно полезными функции преобразования типа оказываются для работы с такими структурами данных, для которых чтение (реализованное как операция преобразования) является тривиальным, а присваивание и инициализация существенно более сложные операции. Функции преобразования нужны для типов istream и ostream, чтобы стали возможными, например, такие операторы:
while (cin>>x) cout<<x;
Операция ввода cin>>x возвращает значение istream&. Оно неявно преобразуется в значение, показывающее состояние потока cin, которое затем проверяется в операторе while (см. $$10.3.2). Но все-таки определять неявное преобразование типа, при котором можно потерять преобразуемое значение, как правило, плохое решение.
Вообще, лучше экономно пользоваться операциями преобразования. Избыток таких операций может вызывать большое число неоднозначностей. Транслятор обнаруживает эти неоднозначности, но разрешить их может быть совсем непросто. Возможно вначале лучше для преобразований использовать поименованные функции, например, X::intof(), и только после того, как такую функцию как следуют опробуют, и явное преобразование типа будет сочтено неэлегантным решением, можно заменить операторной функцией преобразования X::operator int().
Оператор goto
Презираемый оператор goto все-таки есть в С++:
goto идентификатор;
идентификатор: оператор
Вообще говоря, он мало используется в языках высокого уровня, но может быть очень полезен, если текст на С++ создается не человеком, а автоматически, т.е. с помощью программы. Например, операторы goto используются при создании анализатора по заданной грамматике языка с помощью программных средств. Кроме того, операторы goto могут пригодиться в тех случаях, когда на первый план выходит скорость работы программы. Один из них - когда в реальном времени происходят какие-то вычисления во внутреннем цикле программы.
Есть немногие ситуации и в обычных программах, когда применение goto оправдано. Одна из них - выход из вложенного цикла или переключателя. Дело в том, что оператор break во вложенных циклах или переключателях позволяет перейти только на один уровень выше. Приведем пример:
void f()
{
int i;
int j;
for ( i = 0; i < n; i++)
for (j = 0; j<m; j++)
if (nm[i][j] == a) goto found;
// здесь a не найдено
// ...
found:
// nm[i][j] == a
}
Есть еще оператор continue, который позволяет перейти на конец цикла. Что это значит, объяснено в $$3.1.5.
Операторные функции
Можно описать функции, определяющие интерпретацию следующих операций:
+ - * / % ^ & | ~ !
= < > += -= *= /= %= ^= &=
|= << >> >>= <<= == != <= >= &&
|| ++ -- ->* , -> [] () new delete
Последние пять операций означают: косвенное обращение ($$7.9), индексацию ($$7.7), вызов функции ($$7.8), размещение в свободной памяти и освобождение ($$3.2.6). Нельзя изменить приоритеты этих операций, равно как и синтаксические правила для выражений. Так, нельзя определить унарную операцию % , также как и бинарную операцию !. Нельзя ввести новые лексемы для обозначения операций, но если набор операций вас не устраивает, можно воспользоваться привычным обозначением вызова функции. Поэтому используйте pow(), а не ** . Эти ограничения можно счесть драконовскими, но более свободные правила легко приводят к неоднозначности. Допустим, мы определим операцию ** как возведение в степень, что на первый взгляд кажется очевидной и простой задачей. Но если как следует подумать, то возникают вопросы: должны ли операции ** выполняться слева направо (как в Фортране) или справа налево (как в Алголе)? Как интерпретировать выражение a**p как a*(*p) или как (a)**(p)?
Именем операторной функции является служебное слово operator, за которым идет сама операция, например, operator<<. Операторная функция описывается и вызывается как обычная функция. Использование символа операции является просто краткой формой записи вызова операторной функции:
void f(complex a, complex b)
{
complex c = a + b; // краткая форма
complex d = operator+(a,b); // явный вызов
}
С учетом приведенного описания типа complex инициализаторы в этом примере являются эквивалентными.
Операторные функции и пользовательские типы
Операторная функция должна быть либо членом, либо иметь по крайней мере один параметр, являющийся объектом класса (для функций, переопределяющих операции new и delete, это не обязательно). Это правило гарантирует, что пользователь не сумеет изменить интерпретацию выражений, не содержащих объектов пользовательского типа. В частности, нельзя определить операторную функцию, работающую только с указателями. Этим гарантируется, что в С++ возможны расширения, но не мутации (не считая операций =, &, и , для объектов класса).
Операторная функция, имеющая первым параметр основного типа, не может быть функцией-членом. Так, если мы прибавляем комплексную переменную aa к целому 2, то при подходящем описании функции-члена aa+2 можно интерпретировать как aa.operator+(2), но 2+aa так интерпретировать нельзя, поскольку не существует класса int, для которого + определяется как 2.operator+(aa). Даже если бы это было возможно, для интерпретации aa+2 и 2+aa пришлось иметь дело с двумя разными функциями-членами. Этот пример тривиально записывается с помощью функций, не являющихся членами.
Каждое выражение проверяется для выявления неоднозначностей. Если пользовательские операции задают возможную интерпретацию выражения, оно проверяется в соответствии с правилами $$R.13.2.
следует описать прежде, чем оно
Имя (идентификатор) следует описать прежде, чем оно будет использоваться
в программе на С++. Это означает, что нужно указать его тип, чтобы транслятор знал, к какого вида объектам относится имя. Ниже приведены несколько примеров, иллюстрирующих все разнообразие описаний:
char ch;
int count = 1;
char* name = "Njal";
struct complex { float re, im; };
complex cvar;
extern complex sqrt(complex);
extern int error_number;
typedef complex point;
float real(complex* p) { return p->re; };
const double pi = 3.1415926535897932385;
struct user;
template<class T> abs(T a) { return a<0 ? -a : a; }
enum beer { Carlsberg, Tuborg, Thor };
Из этих примеров видно, что роль описаний не сводится лишь к привязке
типа к имени. Большинство указанных описаний одновременно являются определениями, т.е. они создают объект, на который ссылается имя. Для ch, count, name и cvar таким объектом является элемент памяти соответствующего размера. Этот элемент будет использоваться как переменная, и говорят, что для него отведена память. Для real подобным объектом будет заданная функция. Для константы pi объектом будет число 3.1415926535897932385. Для complex объектом будет новый тип. Для point объектом является тип complex, поэтому point становится синонимом complex. Следующие описания уже не являются определениями:
extern complex sqrt(complex);
extern int error_number;
struct user;
Это означает, что объекты, введенные ими, должны быть определены где-то в другом месте программы. Тело функции sqrt должно быть указано в каком-то другом описании. Память для переменной error_number типа int должна выделяться в результате другого описания error_number. Должно быть и какое-то другое описание типа user, из которого можно понять, что это за тип. В программе на языке С++ должно быть только одно определение каждого имени, но описаний может быть много. Однако все описания должны быть согласованы по типу вводимого в них объекта. Поэтому в приведенном ниже фрагменте содержатся две ошибки:
int count;
int count; // ошибка: переопределение
extern int error_number;
extern short error_number; // ошибка: несоответствие типов
Зато в следующем фрагменте нет ни одной ошибки (об использовании extern см. #4.2):
extern int error_number;
extern int error_number;
В некоторых описаниях указываются "значения" объектов, которые они
определяют:
struct complex { float re, im; };
typedef complex point;
float real(complex* p) { return p->re };
const double pi = 3.1415926535897932385;
Для типов, функций и констант "значение" остается неизменным;
для данных, не являющихся константами, начальное значение может впоследствии изменяться:
int count = 1;
char* name = "Bjarne";
//...
count = 2;
name = "Marian";
Из всех определений только следующее не задает значения:
char ch;
Всякое описание, которое задает значение, является определением.
Описания функций
Описание функции содержит ее имя, тип возвращаемого значения (если оно есть) и число и типы параметров, которые должны задаваться при вызове функции. Например:
extern double sqrt(double);
extern elem* next_elem();
extern char* strcpy(char* to, const char* from);
extern void exit(int);
Семантика передачи параметров тождественна семантике инициализации: проверяются типы фактических параметров и, если нужно, происходят неявные преобразования типов. Так, если учесть приведенные описания, то в следующем определении:
double sr2 = sqrt(2);
содержится правильный вызов функции sqrt() со значением с плавающей точкой 2.0. Контроль и преобразование типа фактического параметра имеет в С++ огромное значение.
В описании функции можно указывать имена параметров. Это облегчает чтение программы, но транслятор эти имена просто игнорирует.
Определения функций
Каждая вызываемая в программе функция должна быть где-то в ней определена, причем только один раз. Определение функции - это ее описание, в котором содержится тело функции. Например:
extern void swap(int*, int*); // описание
void swap(int* p, int* q) // определение
{
int t = *p;
*p = *q;
*q = *t;
}
Не так редки случаи, когда в определении функции не используются некоторые параметры:
void search(table* t, const char* key, const char*)
{
// третий параметр не используется
// ...
}
Как видно из этого примера, параметр не используется, если не задано его имя. Подобные функции появляются при упрощении программы или если рассчитывают на ее дальнейшее расширение. В обоих случаях резервирование места в определении функции для неиспользуемого параметра гарантирует, что другие функции, содержащие вызов данной, не придется менять.
Уже говорилось, что функцию можно определить как подстановку (inline). Например:
inline fac(int i) { return i<2 ? 1 : n*fac(n-1); }
Спецификация inline служит подсказкой транслятору, что вызов функции fac можно реализовать подстановкой ее тела, а не с помощью обычного механизма вызова функций ($$R.7.1.2). Хороший оптимизирующий транслятор вместо генерации вызова fac(6) может просто использовать константу 720. Из-за наличия взаиморекурсивных вызовов функций-подстановок, а также функций-подстановок, рекурсивность которых зависит от входных данных, нельзя утверждать, что каждый вызов функции-подстановки действительно реализуется подстановкой ее тела. Степень оптимизации, проводимой транслятором, нельзя формализовать, поэтому одни трансляторы создадут команды 6*5*4*3*2*1, другие - 6*fac(5), а некоторые ограничатся неоптимизированным вызовом fac(6).
Чтобы реализация вызова подстановкой стала возможна даже для не слишком развитых систем программирования, нужно, чтобы не только определение, но и описание функции-подстановки находилось в текущей области видимости. В остальном спецификация inline не влияет на семантику вызова.
Основные типы
Основные типы С++ представляют самые распространенные единицы памяти машин и все основные способы работы с ними. Это:
char
short int
int
long int
Перечисленные типы используются для представления различного размера целых. Числа с плавающей точкой представлены типами:
float
double
long double
Следующие типы могут использоваться для представления без знаковых целых, логических значений, разрядных массивов и т.д.:
unsigned char
unsigned short int
unsigned int
unsigned long int
Ниже приведены типы, которые используются для явного задания знаковых типов:
signed char
signed short int
signed int
signed long int
Поскольку по умолчанию значения типа int считаются знаковыми, то соответствующие типы с signed являются синонимами типов без этого служебного слова. Но тип signed char представляет особый интерес: все 3 типа - unsigned char, signed char и просто char считаются различными (см. также $$R.3.6.1).
Для краткости (и это не влечет никаких последствий) слово int можно не указывать в многословных типах, т.е. long означает long int, unsigned - unsigned int. Вообще, если в описании не указан тип, то предполагается, что это int. Например, ниже даны два определения объекта типа int:
const a = 1; // небрежно, тип не указан
static x; // тот же случай
Все же обычно пропуск типа в описании в надежде, что по умолчанию это будет тип int, считается дурным стилем. Он может вызвать тонкий и нежелательный эффект (см. $$R.7.1).
Для хранения символов и работы с ними наиболее подходит тип char. Обычно он представляет байт из 8 разрядов. Размеры всех объектов в С++ кратны размеру char, и по определению значение sizeof(char) тождественно 1. В зависимости от машины значение типа char может быть знаковым или беззнаковым целым. Конечно, значение типа unsigned char всегда беззнаковое, и, задавая явно этот тип, мы улучшаем переносимость программы. Однако, использование unsigned char вместо char может снизить скорость выполнения программы. Естественно, значение типа signed char всегда знаковое.
В язык введено несколько целых, несколько без знаковых типов и несколько типов с плавающей точкой, чтобы программист мог полнее использовать возможности системы команд. У многих машин значительно различаются размеры выделяемой памяти, время доступа и скорость вычислений для значений различных основных типов. Как правило, зная особенности конкретной машины, легко выбрать оптимальный основной тип (например, один из типов int) для данной переменной. Однако, написать действительно переносимую программу, использующую такие возможности низкого уровня, непросто. Для размеров основных типов выполняются следующие соотношения:
1==sizeof(char)<=sizeof(short)<=sizeof(int)<=sizeof(long)
sizeof(float)<=sizeof(double)<=sizeof(long double)
sizeof(I)==sizeof(signed I)==sizeof(unsigned I)
Здесь I может быть типа char, short, int или long. Помимо этого гарантируется, что char представлен не менее, чем 8 разрядами, short - не менее, чем 16 разрядами и long - не менее, чем 32 разрядами. Тип char достаточен для представления любого символа из набора символов данной машины. Но это означает только то, что тип char может представлять целые в диапазоне 0..127. Предположить большее - рискованно.
Типы беззнаковых целых больше всего подходят для таких программ, в которых память рассматривается как массив разрядов. Но, как правило, использование unsigned вместо int, не дает ничего хорошего, хотя таким образом рассчитывали выиграть еще один разряд для представления положительных целых. Описывая переменную как unsigned, нельзя гарантировать, что она будет только положительной, поскольку допустимы неявные преобразования типа, например:
unsigned surprise = -1;
Это определение допустимо (хотя компилятор может выдать предупреждение
о нем).
Особые ситуации и конструкторы
Особые ситуации дают средство сигнализировать о происходящих в конструкторе ошибках. Поскольку конструктор не возвращает такое значение, которое могла бы проверить вызывающая функция, есть следующие обычные (т.е. не использующие особые ситуации) способы сигнализации:
[1] Возвратить объект в ненормальном состоянии в расчете, что пользователь проверит его состояние.
[2] Установить значение нелокальной переменной, которое сигнализирует, что создать объект не удалось.
Особые ситуации позволяют тот факт, что создать объект не удалось, передать из конструктора вовне:
Vector::Vector(int size)
{
if (sz<0 || max<sz) throw Size();
// ...
}
В функции, создающей вектора, можно перехватить ошибки, вызванные недопустимым размером (Size()) и попытаться на них отреагировать:
Vector* f(int i)
{
Vector* p;
try {
p = new Vector v(i);
}
catch (Vector::Size) {
// реакция на недопустимый размер вектора
}
// ...
return p;
}
Управляющая созданием вектора функция способна правильно отреагировать на ошибку. В самом обработчике особой ситуации можно применить какой-нибудь из стандартных способов диагностики и восстановления после ошибки. При каждом перехвате особой ситуации в управляющей функции может быть свой взгляд на причину ошибки. Если с каждой особой ситуацией передаются описывающие ее данные, то объем данных, которые нужно анализировать для каждой ошибки, растет. Основная задача обработки ошибок в том, чтобы обеспечить надежный и удобный способ передачи данных от исходной точки обнаружения ошибки до того места, где после нее возможно осмысленное восстановление.
Способ "запроса ресурсов путем инициализации" - самый надежное и красивое решение в том случае, когда имеются конструкторы, требующие более одного ресурса. По сути он позволяет свести задачу выделения нескольких ресурсов к повторно применяемому, более простому, способу, рассчитанному на один ресурс.
Особые ситуации и традиционная обработка ошибок
Наш способ обработки ошибок по многим параметрам выгодно отличается от
более традиционных способов. Перечислим, что может сделать операция индексации Vector::operator[]() при обнаружении недопустимого значения индекса:
[1] завершить программу;
[2] возвратить значение, трактуемое как "ошибка";
[3] возвратить нормальное значение и оставить программу в неопределенном состоянии;
[4] вызвать функцию, заданную для реакции на такую ошибку.
Вариант [1] ("завершить программу") реализуется по умолчанию в том
случае, когда особая ситуация не была перехвачена. Для большинства ошибок можно и нужно обеспечить лучшую реакцию.
Вариант [2] ("возвратить значение "ошибка"") можно реализовать
не всегда, поскольку не всегда удается определить значение "ошибка". Так, в нашем примере любое целое является допустимым значением для результата операции индексации. Если можно выделить такое особое значение, то часто этот вариант все равно оказывается неудобным, поскольку проверять на это значение приходится при каждом вызове. Так можно легко удвоить размер программы. Поэтому для обнаружения всех ошибок этот вариант редко используется последовательно.
Вариант [3] ("оставить программу в неопределенном состоянии") имеет тот недостаток, что вызывавшая функция может не заметить ненормального состояния программы. Например, во многих функциях стандартной библиотеки С для сигнализации об ошибке устанавливается соответствующее значение глобальной переменной errno. Однако, в программах пользователя обычно нет достаточно последовательного контроля errno, и в результате возникают наведенные ошибки, вызванные тем, что стандартные функции возвращают не то значение. Кроме того, если в программе есть параллельные вычисления, использование одной глобальной переменной для сигнализации о разных ошибках неизбежно приведет к катастрофе.
Обработка особых ситуаций не предназначалась для тех случаев, на которые рассчитан вариант [4] ( "вызвать функцию реакции на ошибку"). Отметим, однако, что если особые ситуации не предусмотрены, то вместо функции реакции на ошибку можно как раз использовать только один из трех перечисленных вариантов. Обсуждение функций реакций и особых ситуацией будет продолжено в $$9.4.3.
Механизм особых ситуаций успешно заменяет традиционные способы обработки ошибок в тех случаях, когда последние являются неполным, некрасивым или чреватым ошибками решением. Этот механизм позволяет явно отделить часть программы, в которой обрабатываются ошибки, от остальной ее части, тем самым программа становится более понятной и с ней проще работать различным сервисным программам. Свойственный этому механизму регулярный способ обработки ошибок упрощает взаимодействие между раздельно написанными частями программы.
В этом способе обработки ошибок есть для программирующих на С новый момент: стандартная реакция на ошибку (особенно на ошибку в библиотечной функции) состоит в завершении программы. Традиционной была реакция продолжать программу в надежде, что она как-то завершится сама. Поэтому способ, базирующийся на особых ситуациях, делает программу более "хрупкой" в том смысле, что требуется больше усилий и внимания для ее нормального выполнения. Но это все-таки лучше, чем получать неверные результаты на более поздней стадии развития программы (или получать их еще позже, когда программу сочтут завершенной и передадут ничего не подозревающему пользователю). Если завершение программы является неприемлемой реакцией, можно смоделировать традиционную реакцию с помощью перехвата всех особых ситуаций или всех особых ситуаций, принадлежащих специальному классу ($$9.3.2).
Механизм особых ситуаций можно рассматривать как динамический аналог механизма контроля типов и проверки неоднозначности на стадии трансляции. При таком подходе более важной становится стадия проектирования программы, и требуется большая поддержка процесса выполнения программы, чем для программ на С. Однако, в результате получится более предсказуемая программа, ее будет проще встроить в программную систему, она будет понятнее другим программистам и с ней проще будет работать различным сервисным программам. Можно сказать, что механизм особых ситуаций поддерживает, подобно другим средствам С++, "хороший" стиль программирования, который в таких языках, как С, можно применять только не в полном объеме и на неформальном уровне.
Все же надо сознавать, что обработка ошибок остается трудной задачей, и, хотя механизм особых ситуаций более строгий, чем традиционные способы, он все равно недостаточно структурирован по сравнению с конструкциями, допускающими только локальную передачу управления.
Особые ситуации могут не быть ошибками
Если особая ситуация ожидалась, была перехвачена и не оказала плохого воздействия на ход программы, то стоит ли ее называть ошибкой? Так говорят только потому, что программист думает о ней как об ошибке, а механизм особых ситуаций является средством обработки ошибок. С другой стороны, особые ситуации можно рассматривать просто как еще одну структуру управления. Подтвердим это примером:
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(). Использование особых ситуаций как способа возврата может быть элегантным способом завершения функций поиска. Особенно это подходит для рекурсивных функций поиска в дереве. Однако, применяя особые ситуации для таких целей, легко перейти грань разумного и получить маловразумительную программу. Все-таки всюду, где это действительно оправдано, надо придерживаться той точки зрения, что обработка особой ситуации есть обработка ошибки. Обработка ошибок по самой своей природе занятие сложное, поэтому ценность имеют любые методы, которые дают ясное представление ошибок в языке и способ их обработки.
Отношения использования
Для составления и понимания проекта часто необходимо знать, какие классы и каким способом использует данный класс. Такие отношения классов на С++ выражаются неявно. Класс может использовать только те имена, которые где-то определены, но нет такой части в программе на С++, которая содержала бы список всех используемых имен. Для получения такого списка необходимы вспомогательные средства (или, при их отсутствии, внимательное чтение). Можно следующим образом классифицировать те способы, с помощью которых класс X может использовать класс Y:
· X использует имя Y
· X использует Y
- X вызывает функцию-член Y
- X читает член Y
- X пишет в член Y
· X создает Y
- X размещает auto или static переменную из Y
- X создает Y с помощью new
- X использует размер Y
Мы отнесли использование размера объекта к его созданию, поскольку для этого требуется знание полного определения класса. С другой стороны, мы выделили в отдельное отношение использование имени Y, поскольку, указывая его в описании Y* или в описании внешней функции, мы вовсе не нуждаемся в доступе к определению Y:
class Y; // Y - имя класса
Y* p;
extern Y f(const Y&);
Мы отделили создание Y с помощью new от случая описания переменной, поскольку возможна такая реализация С++, при которой для создания Y с помощью new необязательно знать размер Y. Это может быть существенно для ограничения всех зависимостей в проекте и сведения к минимуму перетрансляции после внесения изменений.
Язык С++ не требует, чтобы создатель классов точно определял, какие классы и как он будет использовать. Одна из причин этого заключена в том, что самые важные классы зависят от столь большого количества других классов, что для придания лучшего вида программе нужна сокращенная форма записи списка используемых классов, например, с помощью команды #include. Другая причина в том, что классификация этих зависимостей и, в частности, обЪединение некоторых зависимостей не является обязанностью языка программирования. Наоборот, цели разработчика, программиста или вспомогательного средства определяют то, как именно следует рассматривать отношения использования. Наконец, то, какие зависимости представляют больший интерес, может зависеть от специфики реализации языка.
Отношения принадлежности
Если используется отношение принадлежности, то существует два основных
способа представления объекта класса X:
[1] Описать член типа X.
[2] Описать член типа X* или X&.
Если значение указателя не будет меняться и вопросы эффективности не волнуют, эти способы эквивалентны:
class X {
//...
public:
X(int);
//...
};
class C {
X a;
X* p;
public:
C(int i, int j) : a(i), p(new X(j)) { }
~C() { delete p; }
};
В таких ситуациях предпочтительнее непосредственное членство объекта,
как X::a в примере выше, потому что оно дает экономию времени, памяти и количества вводимых символов. Обратитесь также к $$12.4 и $$13.9.
Способ, использующий указатель, следует применять в тех случаях, когда приходится перестраивать указатель на "объект-элемент" в течении жизни "объекта-владельца". Например:
class C2 {
X* p;
public:
C(int i) : p(new X(i)) { }
~C() { delete p; }
X* change(X* q)
{
X* t = p;
p = q;
return t;
}
};
Член типа указатель может также использоваться, чтобы дать возможность
передавать "объект-элемент" в качестве параметра:
class C3 {
X* p;
public:
C(X* q) : p(q) { }
// ...
}
Разрешая объектам содержать указатели на другие объекты, мы создаем то, что обычно называется "иерархия объектов". Это альтернативный и вспомогательный способ структурирования по отношению к иерархии классов. Как было показано на примере аварийного движущегося средства в $$12.2.2, часто это довольно тонкий вопрос проектирования: представлять ли свойство класса как еще один базовый класс или как член класса. Потребность в переопределении следует считать указанием, что первый вариант лучше. Но если надо иметь возможность представлять некоторое свойство с помощью различных типов, то лучше остановиться на втором варианте. Например:
class XX : public X { /*...*/ };
class XXX : public X { /*...*/ };
void f()
{
C3* p1 = new C3(new X); // C3 "содержит" X
C3* p2 = new C3(new XX); // C3 "содержит" XX
C3* p3 = new C3(new XXX); // C3 "содержит" XXX
//...
}
Приведенные определения нельзя смоделировать ни с помощью производного класса C3 от X, ни с помощью C3, имеющего член типа X, поскольку необходимо указывать точный тип члена. Это важно для классов с виртуальными функциями, таких, например,как класс Shape ($$1.1.2.5), и для класса абстрактного множества ($$13.3).
Заметим, что ссылки можно применять для упрощения классов, использующих члены-указатели, если в течение жизни объекта-владельца ссылка настроена только на один объект, например:
class C4 {
X& r;
public:
C(X& q) : r(q) { }
// ...
};
