|
|
Часть 6
Глава 4 Функции и Файлы
Итерация свойственна человеку,
рекурсия божественна.
- Л. Питер Дойч
Все нетривиальные программы собираются из нескольких раздельно
компилируемых единиц (их принято называть просто файлами). В этой
главе описано, как раздельно откомпилированные функции могут обра-
щаться друг к другу, как такие функции могут совместно пользоваться
данными (разделять данные), и как можно обеспечить согласованность
типов, которые используются в разных файлах программы. Функции
обсуждаются довольно подробно. Сюда входят передача параметров, па-
раметры по умолчанию, перегрузка имен функций, и, конечно же,
описание и определение функций. В конце описываются макросы.
4.1 Введение
Иметь всю программу в одном файле обычно невозможно, поскольку
коды стандартных библиотек и операционной системы находятся где-то
в другом месте. Кроме того, хранить весь текст пользовательской
программы в одном файле как правило непрактично и неудобно. Способ
организации программы в файлы может помочь читающему охватить всю
структуру программы, а также может дать возможность компилятору ре-
ализовать эту структуру. Поскольку единицей компиляции является
файл, то во всех случаях, когда в файл вносится изменение (сколь бы
мало оно ни было), весь файл нужно компилировать заново. Даже для
программы умеренных размеров время, затрачиваемое на перекомпиля-
цию, можно значительно снизить с помощью разбиения программы на
файлы подходящих размеров.
Рассмотрим пример с калькулятором. Он был представлен в виде од-
ного исходного файла. Если вы его набили, то у вас наверняка были
небольшие трудности с расположением описаний в правильном порядке,
и пришлось использовать по меньшей мере одно "фальшивое" описание,
чтобы компилятор смог обработать взаимно рекурсивные функции
expr(), term() и prim(). В тексте уже отмечалось, что программа
состоит из четырех частей (лексического анализатора, программы син-
таксического разбора, таблицы имен и драйвера), но это никак не бы-
ло отражено в тексте самой программы. По сути дела, калькулятор был
написан по-другому. Так это не делается; даже если в этой программе
"на выброс" пренебречь всеми соображениями методологии программиро-
вания, эксплуатации и эффективности компиляции, автор все равно ра-
зобьет эту программу в 200 строк на несколько файлов, чтобы прог-
раммировать было приятнее.
Программа, состоящая из нескольких раздельно компилируемых фай-
лов, должна быть согласованной в смысле использования имен и типов,
точно так же, как и программа, состоящая из одного исходного файла.
В принципе, это может обеспечить и компоновщик*. Компоновщик - это
программа, стыкующая отдельно скомпилированные части вместе. Компо-
новщик часто (путая) называют загрузчиком. В UNIX'е компоновщик на-
зывается ld. Однако компоновщики, имеющиеся в большинстве систем,
обеспечивают очень слабую поддержку проверки согласованности.
Программист может скомпенсировать недостаток поддержки со стороны
компоновщика, предоставив дополнительную информацию о типах (описа-
ния). После этого согласованность программы обеспечивается провер-
кой согласованности описаний, которые находятся в отдельно компили-
руемых частях. Средства, которые это обеспечивают, в вашей системе
будут. С++ разработан так, чтобы способствовать такой явной компо-
новке**.
ДДДДДДДДДДДДДДДДДДДД
* или линкер. (прим. перев.)
** C разработан так, чтобы в большинстве случаев позволять
осуществлять неявную компоновку. Применение C, однако, возросло не-
имоверно, поэтому случаи, когда можно использовать неявную линков-
ку, сейчас составляют незначительное меньшинство. (прим. автора)
4.2 Компоновка
Если не указано иное, то имя, не являющееся локальным для функции
или класса, в каждой части программы, компилируемой отдельно, долж-
но относиться к одному и тому же типу, значению, функции или объек-
ту. То есть, в программе может быть только один нелокальный тип,
значение, функция или объект с этим именем. Рассмотрим, например,
два файла:
// file1.c:
int a = 1; int f() { /* что-то делает */ }
// file2.c:
extern int a; int f(); void g() { a = f(); }
a и f(), используемые g() в файле file2.c,- те же, что определены в
файле file1.c. Ключевое слово extern (внешнее) указывает, что
описание a в file2.c является (только) описанием, а не определени-
ем. Если бы a инициализировалось, extern было бы просто проигнори-
ровано, поскольку описание с инициализацией всегда является опреде-
лением. Объект в программе должен определяться только один раз.
Описываться он может много раз, но типы должны точно согласовы-
ваться. Например:
// file1.c:
int a = 1; int b = 1; extern int c;
// file2.c:
int a; extern double b; extern int c;
Здесь три ошибки: a определено дважды (int a; является определе-
нием, которое означает int a=0;), b описано дважды с разными типа-
ми, а c описано дважды, но не определено. Эти виды ошибок не могут
быть обнаружены компилятором, который за один раз видит только один
файл. Компоновщик, однако, их обнаруживает.
Следующая программа не является С++ программой (хотя C программой
является):
// file1.c:
int a; int f() { return a; }
// file2.c:
int a; int g() { return f(); }
Во-первых, file2.c не С++, потому что f() не была описана, и поэ-
тому компилятор будет недоволен. Во-вторых, (когда file2.c фиксиро-
ван) программа не будет скомпонована, поскольку a определено дваж-
ды.
Имя можно сделать локальным в файле, описав его static. Например:
// file1.c:
static int a = 6; static int f() { /* ... */ }
// file2.c:
static int a = 7; static int f() { /* ... */ }
Поскольку каждое a и f описано как static, получающаяся в резуль-
тате программа является правильной. В каждом файле своя a и своя
f().
Когда переменные и функции явно описаны как static, часть прог-
раммы легче понять (вам не надо никуда больше заглядывать). Исполь-
зование static для функций может, помимо этого, выгодно влиять на
расходы по вызову функции, поскольку дает оптимизирующему компиля-
тору более простую работу.
Рассмотрим два файла:
// file1.c:
const int a = 6; inline int f() { /* ... */ } struct s { int
a,b; }
// file1.c:
const int a = 7; inline int f() { /* ... */ } struct s { int
a,b; }
Раз правило "ровно одно определение" применяется к константам,
inline-функциям и определениям функций так же, как оно применяется
к функциям и переменным, то file1.c и file2.c не могут быть частями
одной С++ программы. Но если это так, то как же два файла могут
использовать одни и те же типы и константы? Коротко, ответ таков:
типы, константы и т.п. могут определяться столько раз, сколько нуж-
но, при условии, что они определяются одинаково. Полный ответ
несколько более сложен (это объясняется в следующем разделе).
4.3 Заголовочные Файлы
Типы во всех описаниях одного и того же объекта должны быть сог-
ласованными. Один из способов это достичь мог бы состоять в обеспе-
чении средств проверки типов в компоновщике, но большинство компо-
новщиков - образца 1950-х, и их нельзя изменить по практическим
соображениям*. Другой подход состоит в обеспечении того, что исход-
ный текст, как он передается на рассмотрение компилятору, или сог-
ласован, или содержит информацию, которая позволяет компилятору об-
наружить несогласованности. Один несовершенный, но простой способ
достичь согласованности состоит во включении заголовочных файлов,
содержащих интерфейсную информацию, в исходные файлы, в которых со-
держится исполняемый код и/или определения данных.
ДДДДДДДДДДДДДДДДДДДД
* Легко изменить один компоновщик, но сделав это и написав
программу, которая зависит от усовершенствований, как вы будете пе-
реносить эту программу в другое место? (прим. автора)
Механизм включения с помощью #include - это чрезвычайно простое
средство обработки текста для сборки кусков исходной программы в
одну единицу (файл) для ее компиляции. Директива
#include "to_be_included"
замещает строку, в которой встретилось #include, содержимым файла
"to_be_included". Его содержимым должен быть исходный текст на С++,
поскольку дальше его будет читать компилятор. Часто включение обра-
батывается отдельной программой, называемой C препроцессором, кото-
рую команда CC вызывает для преобразования исходного файла, который
дал программист, в файл без директив включения перед тем, как на-
чать собственно компиляцию. В другом варианте эти директивы обраба-
тывает интерфейсная система компилятора по мере того, как они
встречаются в исходном тексте. Если программист хочет посмотреть на
результат директив включения, можно воспользоваться командой
CC -E file.c
для препроцессирования файла file.c точно также, как это сделала бы
CC перед запуском собственно компилятора. Для включения файлов из
стандартной директории включения вместо кавычек используются угло-
вые скобки < и >. Например:
#include // из стандартной директории включения
#define "myheader.h" // из текущей директории
Использование <> имеет то преимущество, что в программу факти-
ческое имя директории включения не встраивается (как правило, сна-
чала просматривается /usr/include/CC, а потом usr/include). К сожа-
лению, пробелы в директиве include существенны:
#include < stream.h > // не найдет
Может показаться, что перекомпилировать файл заново каждый раз,
когда он куда-либо включается, расточительно, но время компиляции
такого файла обычно слабо отличается от времени, которое необходимо
для чтения его некоторой заранее откомпилированной формы. Причина в
том, что текст программы является довольно компактным представлени-
ем программы, и в том, что включаемые файлы обычно содержат только
описания и не содержат программ, требующих от компилятора значи-
тельного анализа.
Следующее эмпирическое правило относительно того, что следует, а
что не следует помещать в заголовочные файлы, является не требова-
нием языка, а просто предложением по разумному использованию аппа-
рата #include.
В заголовочном файле могут содержаться:
Определения типов struct point { int x, y; } Описания функций
extern int strlen(const char*); Определения inline-функций
inline char get() { return *p++; } Описания данных extern int
a; Определения констант const float pi = 3.141593 Перечисления
enum bool { false, true }; Директивы include #include
Определения макросов #define Case break;case Коммен-
тарии /* проверка на конец файла */
но никогда
Определения обычных функций char get() { return *p++; } Опреде-
ления данных int a; Определения сложных константных объектов
const tbl[] = { /*
... */ }
В системе UNIX принято, что заголовочные файлы имеют суффикс
(расширение) .h. Файлы, содержащие определение данных или функций,
должны иметь суффикс .c. Такие файлы часто называют, соответствен-
но, ".h файлы" и ".c файлы". В #4.7 описываются макросы. Следует
заметить, что в С++ макросы гораздо менее полезны, чем в C,
поскольку С++ имеет такие языковые конструкции, как const для опре-
деления констант и inline для исключения расходов на вызов функции.
Причина того, почему в заголовочных файлах допускается определе-
ние простых констант, но не допускается определение сложных
константных объектов, прагматическая. В принципе, сложность тут
только в том, чтобы сделать допустимым дублирование определений пе-
ременных (даже определения функций можно было бы дублировать). Од-
нако для компоновщиков старого образца слишком трудно проверять
тождественность нетривиальных констант и убирать ненужные повторы.
Кроме того, простые случаи гораздо более обиходны и потому более
важны для генерации хорошего кода.
4.3.1 Один Заголовочный Файл
Проще всего решить проблему разбиения программы на несколько фай-
лов поместив функции и определения данных в подходящее число исход-
ных файлов и описав типы, необходимые для их взаимодействия, в од-
ном заголовочном файле, который включается во все остальные файлы.
Для программы калькулятора можно использовать четыре .c файла:
lex.c, syn.c, table.c и main.c, и заголовочный файл dc.h, содержа-
щий описания всех имен, которые используются более чем в одном .c
файле:
// dc.h: общие описания для калькулятора
enum token_value { NAME, NUMBER, END, PLUS='+', MINUS='-',
MUL='*', DIV='/', PRINT=';', ASSIGN='=', LP='(', RP=')'
};
extern int no_of_errors; extern double error(char* s); extern
token_value get_token(); extern token_value curr_tok; extern
double number_value; extern char name_string[256];
extern double expr(); extern double term(); extern double prim();
struct name { char* string; name* next; double value;
};
extern name* look(char* p, int ins = 0); inline name*
insert(char* s) { return look(s,1); } Если опустить фактический
код, то lex.c будет выглядеть примерно
так:
// lex.c: ввод и лексический анализ
#include "dc.h"
#include
token_value curr_tok; double number_value; char name_string[256];
token_value get_token() { /* ... */ }
Заметьте, что такое использование заголовочных файлов гарантиру-
ет, что каждое описание в заголовочном файле объекта, определенного
пользователем, будет в какой-то момент включено в файл, где он оп-
ределяется. Например, при компиляции lex.c компилятору будет пере-
дано:
extern token_value get_token();
// ...
token_value get_token() { /* ... */ }
Это обеспечивает то, что компилятор обнаружит любую несогласован-
ность в типах, указанных для имени. Например, если бы get_token()
была описана как возвращающая token_value, но при этом определена
как возвращающая int, компиляция lex.c не прошла бы изза ошибки
несоответствия типов.
Файл syn.c будет выглядеть примерно так:
// syn.c: синтаксический анализ и вычисление
#include "dc.h"
double prim() { /* ... */ } double term() { /* ... */ } double
expr() { /* ... */ }
Файл table.c будет выглядеть примерно так:
// table.c: таблица имен и просмотр
#include "dc.h"
extern char* strcmp(const char*, const char*); extern char*
strcpy(char*, const char*); extern int strlen(const char*);
const TBLSZ = 23; name* table[TBLSZ];
name* look(char* p; int ins) { /* ... */ } Заметьте, что table.c
сам описывает стандартные функции для
работы со строками, поэтому никакой проверки согласованности этих
описаний нет. Почти всегда лучше включать заголовочный файл, чем
описывать имя в .c файле как extern. При этом может включаться
"слишком много", но это обычно не оказывает серьезного влияния на
время, необходимое для компиляции, и как правило экономит время
программиста. В качестве примера этого, обратите внимание на то,
как strlen() заново описывается в main() (ниже). Это лишние нажатия
клавиш и возможный источник неприятностей, поскольку компилятор не
может проверить согласованность этих двух определений. На самом де-
ле, этой сложности можно было бы избежать, будь все описания extern
помещены в dc.h, как и предлагалось сделать. Эта "небрежность" сох-
ранена в программе, поскольку это очень типично для C программ,
очень соблазнительно для программиста, и чаще приводит, чем не при-
водит, к ошибкам, которые трудно обнаружить, и к программам, с ко-
торыми тяжело работать. Вас предупредили!
И main.c, наконец, выглядит так:
// main.c: инициализация, главный цикл и обработка ошибок
#include "dc.h"
int no_of_errors;
double error(char* s) { /* ... */ }
extern int strlen(const char*);
main(int argc, char* argv[]) { /* ... */ }
Важный случай, когда размер заголовочных файлов становится серь-
езной помехой. Набор заголовочных файлов и библиотеку можно исполь-
зовать для расширения языка множеством обще- и специальноприкладных
типов (см. Главы 5-8). В таких случаях не принято осуществлять чте-
ние тысяч строк заголовочных файлов в начале каждой компиляции. Со-
держание этих файлов обычно "заморожено" и изменяется очень не-
часто. Наиболее полезным может оказаться метод затравки компилятора
содержанием этих заголовочных фалов. По сути, создается язык специ-
ального назначения со своим собственным компилятором. Никакого
стандартного метода создания такого компилятора с затравкой не при-
нято.
4.3.2 Множественные Заголовочные Файлы
Стиль разбиения программы с одним заголовочным файлом наиболее
пригоден в тех случаях, когда программа невелика и ее части не
предполагается использовать отдельно. Поэтому то, что невозможно
установить, какие описания зачем помещены в заголовочный файл,
несущественно. Помочь могут комментарии. Другой способ - сделать
так, чтобы каждая часть программы имела свой заголовочный файл, в
котором определяются предоставляемые этой частью средства. Тогда
каждый .c файл имеет соответствующий .h файл, и каждый .c файл
включает свой собственный (специфицирующий то, что в нем задается)
.h файл и, возможно, некоторые другие .h файлы (специфицирующие
то, что ему нужно).
Рассматривая организацию калькулятора, мы замечаем, что error()
используется почти каждой функцией программы, а сама использует
только . Это обычная для функции ошибок ситуация, поэтому
error() следует отделить от main():
// error.h: обработка ошибок
extern int no_errors;
extern double error(char* s);
// error.c
#include
#include "error.h"
int no_of_errors;
double error(char* s) { /* ... */ }
При таком стиле использования заголовочных файлов .h файл и свя-
занный с ним .c файл можно рассматривать как модуль, в котором
.h файл задает интерфейс, а .c файл задает реализацию.
Таблица символов не зависит от остальной части калькулятора за
исключением использования функции ошибок. Это можно сделать явным:
// table.h: описания таблицы имен
struct name { char* string; name* next; double value;
};
extern name* look(char* p, int ins = 0); inline name*
insert(char* s) { return look(s,1); }
// table.c: определения таблицы имен
#include "error.h"
#include
#include "table.h"
const TBLSZ = 23; name* table[TBLSZ];
name* look(char* p; int ins) { /* ... */ } Заметьте, что описания
функций работы со строками теперь
включаются из . Это исключает еще один возможный источник
ошибок.
// lex.h: описания для ввода и лексического анализа
enum token_value { NAME, NUMBER, END, PLUS='+', MINUS='-',
MUL='*', DIV='/', 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
#include
#include "error.h"
#include "lex.h"
token_value curr_tok; double number_value; char name_string[256];
token_value get_token() { /* ... */ }
Интерфейс синтаксического анализатора совершенно прозрачен:
// syn.c: описания для синтаксического анализа и вычисления
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
#include "error.h"
#include "lex.h"
#include "syn.h"
#include "table.h"
#include
main(int argc, char* argv[]) { /* ... */ }
Сколько заголовочных файлов использовать в программе, зависит от
многих факторов. Многие из этих факторов сильнее связаны с тем, как
ваша система работает с заголовочными файлами, нежели с С++. Напри-
мер, если в вашем редакторе нет средств, позволяющих одновременно
видеть несколько файлов, использование большого числа файлов стано-
вится менее привлекательным. Аналогично, если открывание и чтение
10 файлов по 50 строк в каждом требует заметно больше времени, чем
чтение одного файла в 500 строк, вы можете дважды подумать, прежде
чем использовать в небольшом проекте стиль множественных заголовоч-
ных файлов. Слово предостережения: набор из десяти заголовочных
файлов плюс стандартные заголовочные файлы обычно легче поддаются
управлению. С другой стороны, если вы разбили описания в большой
программе на логически минимальные по размеру заголовочные файлы
(помещая каждое описание структуры в свой отдельный файл и т.д.), у
вас легко может получиться неразбериха из сотен файлов.
4.3.3 Сокрытие Данных
Используя заголовочные файлы пользователь может определять явный
интерфейс, чтобы обеспечить согласованное использование типов в
программе. С другой стороны, пользователь может обойти интерфейс,
задаваемый заголовочным файлом, вводя в .c файлы описания extern.
Заметьте, что такой стиль компоновки не рекомендуется:
// file1.c: // "extern" не используется
int a = 7; const c = 8; void f(long) { /* ... */ }
// file2.c: // "extern" в .c файле
extern int a; extern const c; extern f(int); int g() { return
f(a+c); }
Поскольку описания extern в file2.c не включаются вместе с опре-
делениями в файле file1.c, компилятор не может проверить согласо-
ванность этой программы. Следовательно, если только загрузчик не
окажется гораздо сообразительнее среднего, две ошибки в этой прог-
рамме останутся, и их придется искать программисту.
Пользователь может защитить файл от такой недисциплинированной
компоновки, описав имена, которые не предназначены для общего поль-
зования, как static, чтобы их областью видимости был файл, и они
были скрыты от остальных частей программы. Например:
// table.c: определения таблицы имен
#include "error.h"
#include
#include "table.h"
const TBLSZ = 23; static name* table[TBLSZ];
name* look(char* p; int ins) { /* ... */ }
Это гарантирует, что любой доступ к table действительно будет
осуществляться именно через look(). "Прятать" константу TBLSZ не
обязательно.
4.4 Файлы как Модули
В предыдущем разделе .c и .h файлы вместе определяли часть прог-
раммы. Файл .h является интерфейсом, который используют другие
части программы, .c файл задает реализацию. Такой объект часто на-
зывают модулем. Доступными делаются только те имена, которые необ-
ходимо знать пользователю, остальные скрыты. Это качество часто на-
зывают сокрытием данных, хотя данные - лишь часть того, что может
быть скрыто. Модули такого вида обеспечивают большую гибкость. Нап-
ример, реализация может состоять из одного или более
.c файлов, и в виде .h файлов может быть предоставлено несколько
интерфейсов. Информация, которую пользователю знать не обязательно,
искусно скрыта в .c файлах. Если важно, что пользователь не должен
точно знать, что содержится в .c файлах, не надо делать их доступ-
ными в исходом виде. Достаточно эквивалентных им выходных файлов
компилятора (.o файлов).
Иногда возникает сложность, состоящая в том, что подобная гиб-
кость достигается без формальной структуры. Сам язык не распознает
такой модуль как объект, и у компилятора нет возможности отличить
.h файлы, определяющие имена, которые должны использовать другие
модули (экспортируемые), от .h файлов, которые описывают имена из
других модулей (импортируемые).
В других случаях может возникнуть та проблема, что модуль опреде-
ляет множество объектов, а не новый тип. Например, модуль table оп-
ределяет одну таблицу, и если вам нужно две таблицы, то нет просто-
го способа задать вторую таблицу с помощью понятия модуля. Решение
этой проблемы приводится в Главе 5.
Каждый статически размещенный объект по умолчанию инициализиру-
ется нулем, программист может задать другие (константные) значения.
Это только самый примитивный вид инициализации. К счастью, с по-
мощью классов можно задать код, который выполняется для инициализа-
ции перед тем, как модуль какимлибо образом используется, и/или
код, который запускается для очистки после последнего использования
модуля, см. #5.5.2.
4.5 Как Создать Библиотеку
Фразы типа "помещен в библиотеку" и "ищется в какой-то библиоте-
ке" используются часто (и в этой книге, и в других), но что это оз-
начает для С++ программы? К сожалению, ответ зависит от того, какая
операционная система используется; в этом разделе объясняется, как
создать библиотеку в 8-ой версии системы UNIX. Другие системы пре-
доставляют аналогичные возможности.
Библиотека в своей основе является множеством .o файлов, получен-
ных в результате компиляции соответствующего множества .c файлов.
Обычно имеется один или более .h файлов, в которых содержатся
описания для использования этих .o файлов. В качестве примера
рассмотрим случай, когда нам надо задать (обычным способом) набор
математических функций для некоторого неопределенного множества
пользователей. Заголовочный файл мог бы выглядеть примерно так:
extern double sqrt(double); // подмножество extern
double sin(double); extern double cos(double); extern double
exp(double); extern double log(double);
а определения этих функций хранились бы, соответственно, в файлах
sqrt.c, sin.c, cos.c, exp.c и log.c.
Библиотеку с именем math.h можно создать, например, так:
$ CC -c sqrt.c sin.c cos.c exp.c log.c
$ ar cr math.a sqrt.o sin.o cos.o exp.o log.o
$ ranlib math.a
Вначале исходные файлы компилируются в эквивалентные им объектные
файлы. Затем используется команда ar, чтобы создать архив с именем
math.a. И, наконец, этот архив индексируется для ускорения доступа.
Если в вашей системе нет ranlib команды, значит она вам, вероятно,
не понадобится. Подробности посмотрите, пожалуйста, в вашем руко-
водстве в разделе под заголовком ar. Использовать библиотеку можно,
например, так:
$ CC myprog.c math.a
Теперь разберемся, в чем же преимущества использования math.a пе-
ред просто непосредственным использованием .o файлов? Например:
$ CC myprog.c sqrt.o sin.o cos.o exp.o log.o
Для большинства программ определить правильный набор .o файлов,
несомненно, непросто. В приведенном выше примере они включались
все, но если функции в myprog.c вызывают только функции sqrt() и
cos(), то кажется, что будет достаточно
$ CC myprog.c sqrt.o cos.o
Но это не так, поскольку cos.c использует sin.c.
Компоновщик, вызываемый командой CC для обработки .a файла (в
данном случае, файла math.a) знает, как из того множества, которое
использовалось для создания .a файла, извлечь только необходимые
.o файлы.
Другими словами, используя библиотеку можно включать много опре-
делений с помощью одного имени (включения определений функций и пе-
ременных, используемых внутренними функциями, никогда не видны
пользователю), и, кроме того, обеспечить, что в результате в прог-
рамму будет включено минимальное количество определений.
4.6 Функции
Обычный способ сделать что-либо в С++ программе - это вызвать
функцию, которая это делает. Определение функции является способом
задать то, как должно делаться некоторое действие. Функция не может
быть вызвана, пока она не описана.
4.6.1 Описания Функций
Описание функции задает имя функции, тип возвращаемого функцией
значения (если таковое есть) и число и типы параметров, которые
должны быть в вызове функции. Например:
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. Значение такой проверки типа и преобразования типа
огромно.
Описание функции может содержать имена параметров. Это может по-
мочь читателю, но компилятор эти имена просто игнорирует.
4.6.2 Определения Функций
Каждая функция, вызываемая в программе, должна быть где-то опре-
делена (только один раз). Определение функции - это описание функ-
ции, в котором приводится тело функции. Например:
extern void swap(int*, int*); // описание
void swap(int*, int*) // определение {
int t = *p;
*p =*q;
*q = t;
}
Чтобы избежать расходов на вызов функции, функцию можно описать
как inline (#1.12), а чтобы обеспечить более быстрый доступ к пара-
метрам, их можно описать как register (#2.3.11). Оба средства могут
использоваться неправильно, и их следует избегать везде где есть
какие-либо сомнения в их полезности.
4.6.3 Передача Параметров
Когда вызывается функция, дополнительно выделяется память под ее
формальные параметры, и каждый формальный параметр инициализируется
соответствующим ему фактическим параметром. Семантика передачи па-
раметров идентична семантике инициализации. В частности, тип факти-
ческого параметра сопоставляется с типом формального параметра, и
выполняются все стандартные и определенные пользователем преобразо-
вания типов. Есть особые правила для передачи векторов (#4.6.5),
средство передавать параметр без проверки типа параметра (#4.6.8) и
средство для задания параметров по умолчанию (#4.6.6). Рассмотрим
void f(int val, int& ref) {
val++; ref++;
}
Когда вызывается f(), val++ увеличивает локальную копию первого
фактического параметра, тогда как ref++ увеличивает второй факти-
ческий параметр. Например:
int i = 1; int j = 1; f(i,j);
увеличивает j, но не i. Первый параметр - i, передается по значе-
нию, второй параметр - j, передается по ссылке. Как уже отмечалось
в #2.3.10, использование функций, которые изменяют переданные по
ссылке параметры, могут сделать программу трудно читаемой, и их
следует избегать (но см. #6.5 и #8.4). Однако передача большого
объекта по ссылке может быть гораздо эффективнее, чем передача его
по значению. В этом случае параметр можно описать как const, чтобы
указать, что ссылка применяется по соображениям эффективности, а
также чтобы не позволить вызываемой функции изменять значение объ-
екта:
void f(const large& arg) {
// значение "arg" не может быть изменено
}
Аналогично, описание параметра указателя как const сообщает чита-
телю, что значение объекта, указываемого указателем, функцией не
изменяется. Например:
extern int strlen(const char*); // из extern char*
strcpy(char* to, const char* from); extern int strcmp(const
char*, const char*);
Важность такой практики возрастает с размером программы.
Заметьте, что семантика передачи параметров отлична от семантики
присваивания. Это важно для const параметров, ссылочных параметров
и параметров некоторых типов, определяемых пользователем (#6.6).
4.6.4 Возврат Значения
Из функции, которая не описана как void, можно (и должно) возвра-
щать значение. Возвращаемое значение задается оператором return.
Например:
int fac(int n) {return (n>1) ? n*fac(n-1) : 1; }
В функции может быть больше одного оператора return:
int fac(int n) {
if (n > 1) return n*fac(n-1);
else return 1;
}
Как и семантика передачи параметров, семантика возврата функцией
значения идентична семантике инициализации. Возвращаемое значение
рассматривается как инициализатор переменной возвращаемого типа.
Тип возвращаемого выражения проверяется на согласованность с возв-
ращаемым типом и выполняются все стандартные и определенные пользо-
вателем преобразования типов. Например:
double f() {
// ...
return 1; // неявно преобразуется к double(1)
}
Каждый раз, когда вызывается функция, создается новая копия ее
параметров и автоматических переменных. После возврата из функции
память используется заново, поэтому возвращать указатель на локаль-
ную переменную неразумно. Содержание указываемого места изменится
непредсказуемо:
int* f() { int local = 1; // ... return &local; // так не делайте
}
Эта ошибка менее обычна, чем эквивалентная ошибка при использова-
нии ссылок:
int& f() { int local = 1; // ... return local; // так не делайте
}
К счастью, о таких возвращаемых значениях предупреждает компиля-
тор. Вот другой пример:
int& f() { return 1;} // так не делайте
4.6.5 Векторные Параметры
Если в качестве параметра функции используется вектор, то переда-
ется указатель на его первый элемент. Например:
int strlen(const char*);
void f() {
char v[] = "a vector" strlen(v); strlen("Nicholas");
};
Иначе говоря, при передаче как параметр параметр типа T[] преоб-
разуется к T*. Следовательно, присваивание элементу векторного па-
раметра изменяет значение элемента вектора, который является пара-
метром. Другими словами, вектор отличается от всех остальных типов
тем, что вектор не передается (и не может передаваться) по значе-
нию.
Размер вектора недоступен вызываемой функции. Это может быть неу-
добно, но эту сложность можно обойти несколькими способами. Строки
оканчиваются нулем, поэтому их размер можно легко вычислить. Для
других векторов можно передавать второй параметр, который задает
размер, или определить тип, содержащий указатель и индикатор длины,
и передавать его вместо просто вектора (см. также #1.11). Например:
void compute1(int* vec_ptr, int vec_size); // один способ
struct vec { // другой способ int* ptr; int size;
};
void compute2(vec v);
С многомерными массивами все хитрее, но часто можно вместо них
использовать векторы указателей, которые не требуют специального
рассмотрения. Например:
char* day[] = { "mon", "tue", "wed", "thu", "fri", "sat", "sun"
};
С другой стороны, рассмотрим определение функции, которая работа-
ет с двумерными матрицами. Если размерность известна на стадии ком-
пиляции, то никаких проблем нет:
void print_m34(int m[3][4]) {
for (int i = 0; i<3; i++) { for (int j = 0; j<4; j++)
cout << " " << m[i][j]; cout << "\n";
}
}
Матрица, конечно, все равно передается как указатель, а размер-
ности используются просто для удобства записи.
Первая размерность массива не имеет отношения к задаче поиска по-
ложения элемента (#2.3.6). Поэтому ее можно передавать как пара-
метр:
void print_mi4(int m[][4], int dim1) {
for (int i = 0; i complex pow(double, complex); // из
complex pow(complex, int); complex pow(complex, double); complex
pow(complex, complex);
Процесс поиска подходящей функции игнорирует unsigned и const.
4.6.8 Незаданное Число Параметров
Для некоторых функций невозможно задать число и тип всех парамет-
ров, которые можно ожидать в вызове. Такую функцию описывают завер-
шая список описаний параметров многоточием (...), что означает "и
может быть, еще какие-то неописанные параметры". Например:
int printf(char* ...);
Это задает, что в вызове printf должен быть по меньшей мере один
параметр, char*, а остальные могут быть, а могут и не быть. Напри-
мер:
printf("Hello, world\n"); printf("Мое имя %s %s\n", first_name,
second_name); printf("%d + %d = %d\n",2,3,5);
Такая функция полагается на информацию, которая недоступна компи-
лятору при интерпретации ее списка параметров. В случае printf()
первым параметром является строка формата, содержащая специальные
последовательности символов, позволяющие printf() правильно обраба-
тывать остальные параметры. %s означает "жди параметра char*", а %d
означает "жди параметра int". Однако, компилятор этого не знает,
поэтому он не может убедиться в том, что ожидаемые параметры имеют
соответствующий тип. Например:
printf("Мое имя %s %s\n",2);
откомпилируется и в лучшем случае приведет к какой-нибудь странного
вида выдаче.
Очевидно, если параметр не был описан, то у компилятора нет ин-
формации, необходимой для выполнения над ним проверки типа и преоб-
разования типа. В этом случае char или short передаются как int, а
float передается как double. Это не обязательно то, чего ждет поль-
зователь.
Чрезмерное использование многоточий, вроде wild(...), полностью
выключает проверку типов параметров, оставляя программиста открытым
перед множеством неприятностей, которые хорошо знакомы програм-
мистам на C. В хорошо продуманной программе требуется самое большее
несколько функций, для которых типы параметров не определены пол-
ностью. Для того, чтобы позаботиться о проверке типов, можно
использовать перегруженные функции и функции с параметрами по умол-
чанию в большинстве тех случаев, когда иначе пришлось бы оставить
типы параметров незаданными. Многоточие необходимо только если из-
меняются и число параметров, и тип параметров. Наиболее обычное
применение многоточия в задании интерфейса с функциями C библиотек,
которые были определены в то время, когда альтернативы не было:
extern int fprintf(FILE*, char* ...); // из extern int
execl(char* ...); // из extern int abort(...); // из
Стандартный набор макросов, имеющийся для доступа к неспецифици-
рованным параметрам в таких функциях, можно найти в .
Разберем случай написания функции ошибок, которая получает один це-
лый параметр, указывающий серьезность ошибки, после которого идет
произвольное число строк. Идея состоит в том, чтобы составлять
сообщение об ошибке с помощью передачи каждого слова как отдельного
строкового параметра:
void error(int ...);
main(int argc, char* argv[]) {
switch(argc) { case 1:
error(0,argv[0],0); break;
case 2:
error(0,argv[0],argv[1],0); default:
error(1,argv[0],"с",dec(argc-1),"параметрами",0);
}
}
Функцию ошибок можно определить так:
#include
void error(int n ...)
/*
"n" с последующим списком char*, оканчивающихся нулем
*/
{ va_list ap; va_start(ap,n); // раскрутка arg
for (;;) { char* p = va_arg(ap,char*); if(p == 0) break; cerr
<< p << " "; }
va_end(ap); // очистка arg
cerr << "\n"; if (n) exit(n);
}
Первый из va_list определяется и инициализируется вызовом
va_start(). Макрос va_start получает имя va_list'а и имя последнего
формального параметра как параметры. Макрос va_arg используется для
выбора неименованных параметров по порядку. При каждом обращении
программист должен задать тип; va_arg() предполагает, что был пере-
дан фактический параметр, но обычно способа убедиться в этом нет.
Перед возвратом из функции, в которой был использован va_start(),
должен быть вызван va_end(). Причина в том, что va_start() может
изменить стек так, что нельзя будет успешно осуществить возврат;
va_end() аннулирует все эти изменения.
4.6.9 Указатель на Функцию
С функцией можно делать только две вещи: вызывать ее и брать ее
адрес. Указатель, полученный взятием адреса функции, можно затем
использовать для вызова этой функции. Например:
void error(char* p) { /* ... */ }
void (*efct)(char*); // указатель на функцию
void f() {
efct = &error; // efct указывает на error (*efct)("error");
// вызов error через efct
}
Чтобы вызвать функцию через указатель, например, efct, надо сна-
чала этот указатель разыменовать, *efct. Поскольку операция вызова
функции () имеет более высокий приоритет, чем операция разыменова-
ния *, то нельзя писать просто *efct("error"). Это означает
*efct("error"), а это ошибка в типе. То же относится и к синтаксису
описаний (см. также #7.3.4).
Заметьте, что у указателей на функции типы параметров описываются
точно также, как и в самих функциях. В присваиваниях указателя
должно соблюдаться точное соответствие полного типа функции. Напри-
мер:
void (*pf)(char*); // указатель на void(char*) void f1(char*); //
void(char*) int f2(char*); // int(char*) void f3(int*); //
void(int*)
void f() {
pf = &f1; // ok pf = &f2; // ошибка: не подходит возвращаемый
тип pf = &f3; // ошибка: не подходит тип параметра
(*pf)("asdf"); // ok (*pf)(1); // ошибка: не подходит тип па-
раметра
int i = (*pf)("qwer"); // ошибка: void присваивается int'у
}
Правила передачи параметров для непосредственных вызовов функции
и для вызовов функции через указатель одни и те же.
Часто, чтобы избежать использования какого-либо неочевидного син-
таксиса, бывает удобно определить имя типа указатель-на-функцию.
Например:
typedef int (*SIG_TYP)(); // из typedef void
(*SIG_ARG_TYP); SIG_TYP signal(int,SIG_ARG_TYP);
Бывает часто полезен вектор указателей на функцию. Например,
система меню для моего редактора с мышью* реализована с помощью
векторов указателей на функции для представления действий. Подробно
эту систему здесь описать не получится, но вот общая идея:
typedef void (*PF)();
PF edit_ops[] = { // операции редактирования cut, paste, snarf,
search
};
PF file_ops[] = { // управление файлом open, reshape, close,
write
};
ДДДДДДДДДДДДДДДДДДДД
* Мышь - это указывающее устройство по крайней мере с одной
кнопкой. Моя мышь красная, круглая и с тремя кнопками. (прим. авто-
ра)
Затем определяем и инициализируем указатели, определяющие
действия, выбранные в меню, которое связано с кнопками (button) мы-
ши:
PF* button2 = edit_ops; PF* button3 = file_ops;
В полной реализации для определения каждого пункта меню требуется
больше информации. Например, где-то должна храниться строка, задаю-
щая текст, который высвечивается. При использовании системы значе-
ние кнопок мыши часто меняется в зависимости от ситуации. Эти изме-
нения осуществляются (частично) посредством смены значений указате-
лей кнопок. Когда пользователь выбирает пункт меню, например пункт
3 для кнопки 2, выполняется связанное с ним действие:
(button2[3])();
Один из способов оценить огромную мощь указателей на функции -
это попробовать написать такую систему не используя их. Меню можно
менять в ходе использования программы, внося новые функции в табли-
цу действий. Во время выполнения можно также легко сконструировать
новое меню.
Указатели на функции можно использовать для задания полиморфных
подпрограмм, то есть подпрограмм, которые могут применяться к объ-
ектам многих различных типов:
typedef int (*CFT)(char*,char*);
int sort(char* base, unsigned n, int sz, CFT cmp)
/*
Сортирует "n" элементов вектора "base" в возрастающем порядке
с помощью функции сравнения, указываемой "cmp". Размер эле-
ментов "sz".
Очень неэффективный алгоритм: пузырьковая сортировка
*/
{ for (int i=0; iname, Puser(q)->name);
}
int cmp2(char*p, char* q) // Сравнивает числа dept {
return Puser(p)->dept-Puser(q)->dept;
}
Эта программа сортирует и печатает:
main () {
sort((char*)heads,6,sizeof(user),cmp1); print_id(heads,6); //
в алфавитном порядке cout << "\n";
sort((char*)heads,6,sizeof(user),cmp2); print_id(heads,6); //
по порядку подразделений
}
Можно взять адрес inline-функции, как, впрочем, и адрес перегру-
женной функции(#с.8.9).
4.7 Макросы
Макросы* определяются в #с.11. В C они очень важны, но в С++ при-
меняются гораздо меньше. Первое правило относительно них такое: не
используйте их, если вы не обязаны это делать. Как было замечено,
почти каждый макрос проявляет свой изъян или в языке, или в прог-
рамме. Если вы хотите использовать макросы, прочитайте, пожалуйста,
вначале очень внимательно руководство по вашей реализации C препро-
цессора.
Простой макрос определяется так:
#define name rest of line
Когда name встречается как лексема, оно заменяется на rest of
line. Например:
named = name
после расширения даст:
named = rest of line
Можно также определить макрос с параметрами. Например:
#define mac(a,b) argument1: a argument2: b
При использовании mac должно даваться две строки параметра. После
расширения mac() они заменяют a и b. Например:
expanded = mac(foo bar, yuk yuk)
после расширения даст
expanded = argument1: foo bar argument2: yuk yuk
Макросы обрабатывают строки и о синтаксисе С++ знают очень мало,
а о типах С++ или областях видимости - ничего. Компилятор видит
только расширенную форму макроса, поэтому ошибка в макросе диаг-
ностируется когда макрос расширен, а не когда он определен. В ре-
зультате этого возникают непонятные сообщения об ошибках.
ДДДДДДДДДДДДДДДДДДДД
* часто называемые также макроопределениями. (прим. перев.)
Вот такими макросы могут быть вполне:
#define Case break;case
#define nl <<"\n"
#define forever for(;;)
#define MIN(a,b) (((a)<(b))?(a):(b))
Вот совершенно ненужные макросы:
#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)
и заключайте вхождения имени параметра макроса в скобки везде, где
это возможно (см. MIN выше).
Обратите внимание на различие результатов расширения этих двух
макросов:
#define m1(a) something(a) // глубокомысленный комментарий
#define m2(a) something(a) /* глубокомысленный комментарий */
например,
int a = m1(1)+2; int b = m2(1)+2;
расширяется в
int a = something(1) // глубокомысленный комментарий+2; int b =
something(1) /* глубокомысленный комментарий */+2;
С помощью макросов вы можете разработать свой собственный язык.
Скорее всего, для всех остальных он будет непостижим. Кроме того, C
препроцессор - очень простой макропроцессор. Когда вы попытаетесь
сделать что-либо нетривиальное, вы, вероятно, обнаружите, что сде-
лать это либо невозможно, либо чрезвычайно трудно (но см. #7.3.5).
4.8 Упражнения
1. (*1) Напишите следующие описания: функция, получающая параметр
типа указатель на символ и ссылку на целое и не возвращающая
значения; указатель на такую функцию; функция, получающая та-
кой указатель в качестве параметра; и функция, возвращающая
такой указатель. Напишите определение функции, которая получа-
ет такой указатель как параметр и возвращает свой параметр как
возвращаемое значение. Подсказка: используйте typedef.
2. (*1) Что это значит? Для чего это может использоваться?
typedef int (rifii&) (int, int);
3. (*1.5) Напишите программу вроде "Hello, world", которая полу-
чает имя как параметр командной строки и печатает "Hello,
имя". Модифицируйте эту программу так, чтобы она получала по-
лучала любое количество имен и говорила hello каждому из них.
4. (*1.5) Напишите программу, которая читает произвольное число
файлов, имена которых задаются как аргументы командной стоки,
и пишет их один за другим в cout. Поскольку эта программа при
выдаче конкатинирует свои параметры, вы можете назвать ее cat
(кошка).
5. (*2) Преобразуйте небольшую C программу в С++. Измените заго-
ловочные файлы так, чтобы описывать все вызываемые функции и
описывать тип каждого параметра. Замените, где возможно, ди-
рективы #define на enum и const или inline. Уберите из .c фай-
лов описания extern и преобразуйте определения функций к син-
таксису С++. Замените вызовы malloc() и free() на new и
delete. Уберите необязательные приведения типа.
6. (*2) Реализуйте sort() (#4.6.7) используя эффективный алгоритм
сортировки.
7. (*2) Посмотрите на определение struct tnode в с.#8.5. Напишите
функцию для введения новых слов в дерево узлов tnode. Напишите
функцию для вывода дерева узлов tnode. Напишите функцию для
вывода дерева узлов tnode со словами в алфавитном порядке. Мо-
дифицируйте tnode так, чтобы в нем хранился (только) указатель
на слово произвольной длины, помещенное с помощью new в сво-
бодную память. Модифицируйте функции для использования нового
определения tnode.
8. (*2) Напишите "модуль", реализующий стек. Файл .h должен
описывать функции push(), pop() и любые другие удобные функции
(только). Файл .c определяет функции и данные, необходимые для
хранения стека.
9. (*2) Узнайте, какие у вас есть стандартные заголовочные файлы.
Составьте список файлов, находящихся в /usr/include и
/usr/include/CC (или там, где хранятся стандартные заголовоч-
ные файлы в вашей системе). Прочитайте все, что покажется ин-
тересным.
10. (*2) Напишите функцию для обращения двумерного массива.
11. (*2) Напишите зашифровывающую программу, которая читает из
cin и пишет в cout закодированные символы. Вы можете восполь-
зоваться следующей простой схемой шифровки: Зашифрованная фор-
ма символа c - это c^key[i], где key (ключ) - строка, которая
передается как параметр командной строки. Программа использует
символы из key циклически, пока не будет считан весь ввод. Пе-
рекодирование зашифрованного текста с той же строкой key дает
исходный текст. Если не передается никакого ключа (или переда-
ется пустая строка), то никакого кодирования не делается.
12. (*3) Напишите программу, которая поможет расшифровывать
тексты, зашифрованные описанным выше способом, не зная ключа.
Подсказка: David Kahn: The Code-Breakers, Macmillan, 1967, New
York, pp 207-213.
13. (*3) Напишите функцию error, которая получает форматную стро-
ку в стиле printf, которая содержит директивы %s, %c и %d, и
произвольное количество параметров. Не используйте printf().
Если вы не знаете значения %s и т.д., посмотрите #8.2.4.
Используйте .
14. (*1) Как бы вы выбирали имени для типов указателя на функцию,
определенных с помощью typedef?
15. (*2) Посмотрите какие-нибудь программы, чтобы создать
представление о разнообразии стилей и имен, использующихся на
практике. Как используются буквы в верхнем регистре? Как
используется подчерк? Где используются короткие имена вроде x
и y?
16. (*1) Что неправильно в следующих макроопределениях?
#define PI = 3.141593
#define MAX(a,b) a>b?a:b
#define fac(a) (a)*fac((a)-1)
17. (*3) Напишите макропроцессор, который определяет и расширяет
простые макросы (как C препроцессор). Читайте из cin и пишите
в cout. Сначала не пытайтесь обрабатывать макросы с параметра-
ми. Подсказка: В настольном калькуляторе (#3.1) есть таблица
имен и лексический анализатор, которые вы можете модифициро-
вать.
|
|