Страница:
Неправильное использование комментариев может серьезно повлиять на удобочитаемость программы, Компилятор не понимает содержание комментария, поэтому он никаким способом не может убедиться в том, что комментарий
1. осмыслен,
2. описывает программу и
3. не устарел.
Непонятные, двусмысленные и просто неправильные комметарии содержатся в большинстве программ. Плохой комментарий может быть хуже, чем никакой.
Если что-то можно сформулировать средствами самого язка, следует это сделать, а не просто отметить в комментарии. Данное замечание относится к комментариям вроде:
// переменная "v" должна быть инициализирована.
//переменная"v"должна использоваться только функцией «f()».
// вызвать функцию init() перед вызовом // любой другой функции в этом файле.
// вызовите функцию очистки «cleanup()» в конце вашей // программы.
// не используйте функцию «wierd()».
// функция «f()» получает два параметра.
При правильном использовании С++ подобные комментарии как правило становятся ненужными. Чтобы предыдущие комментрии стали излишними, можно, например, использовать правила компоновки (#4.2) и видимость, инициализацию и правила очиски для классов (см. #5.5.2).
Если что-то было ясно сформулировано на языке, второй раз упоминать это в комментарии не следует. Например:
a = b+c; // a становится b+c count++; // увеличить счетчик
Такие комментарии хуже чем просто излишни, они увеличвают объем текста, который надо прочитать, они часто затумнивают структуру программы, и они могут быть неправильными.
Автор предпочитает:
1. Комментарий для каждого исходного файла, сообщающий, для чего в целом предназначены находящиеся в нем комментарии, дающий ссылки на справочники и руководства, общие рекомендции по использованию и т.д.,
2. Комментарий для каждой нетривиальной функции, в ктором сформулировано ее назначение, используемый алгоритм (если он неочевиден) и, быть может, что-то о принимаемых в ней предположениях относительно среды выполнения,
3. Небольшое число комментариев в тех местах, где прорамма неочевидна и/или непереносима и
4. Очень мало что еще.
Например:
// tbl.c: Реализация таблицы имен /* Гауссовское исключение с частичным См. Ralston: «A first course ...» стр. 411. */
// swap() предполагает размещение стека AT amp;T sB20.
/**************************************
Copyright (c) 1984 AT amp;T, Inc. All rights reserved
****************************************/
Удачно подобранные и хорошо написанные комментарии – сщественная часть программы. Написание хороших комментариев может быть столь же сложным, сколь и написание самой програмы.
Заметьте также, что если в функции используются исключтельно комментарии //, то любую часть этой функции можно зкомментировать с помощью комментариев /* */, и наоборот.
3.5 Упражнения
1. (*1) Перепишите следующий оператор for в виде эквивалентного оператора while: for (i=0; i«max_length; i++) if (input_line[i] == '?') quest_count++;
2. (*1) Полностью расставьте скобки в следующих выражниях: a = b + c * d «« 2 amp; 8 a amp; 077 != 3 a == b !! a == c amp; amp; c « 5 c = x != 0 0 «= i « 7 f(1,2)+3 a = -1 + + b – – 5 a = b == c ++ a = b = c = 0 a[4][2] *= * b ? c : * d * 2 a-b,c=d
3. (*2) Найдите пять различных конструкций С++, значение которых неопределено.
4. (*2) Найдите десять различных примеров непереносимой С++ программы.
5. (*1) Что происходит в вашей системе, если вы делите на ноль? Что происходит при переполнении и потере значимости?
6. (*1) Полностью расставьте скобки в следующих выражниях: *p++ *–p ++a– (int*)p-»m *p.m *a[i]
7. (*2) Напишите функции: strlen(), которая возвращает длину строки, strcpy(), которая копирует одну строку в дргую, и strcmp(), которая сравнивает две строки. Разберитесь, какие должны быть типы параметров и типы возвращаемых значний, а потом сравните их со стандартными версиями, которые описаны в «string.h» и в вашем руководстве.
8. (*1) Посмотрите, как ваш компилятор реагирует на ошибки: a := b+1; if (a = 3) // ... if (a amp;077 == 0) // Придумайте ошибки попроще, и посмотрите, как компилятор на них реагирует.
9. (*2) Напишите функцию cat(), получающую два строковых параметра и возвращающую строку, которая является конкатенцией параметров. Используйте new, чтобы найти память для рзультата. Напишите функцию rev(), которая получает строку и переставляет в ней символы в обратном порядке. То есть, после вызова rev(p) последний символ p становится первым.
10. (*2) Что делает следующая программа?
void send(register* to, register* from, register count) // Полезные комментарии несомненно уничтожены. (* register n=(count+7)/8; switch (count%8) (* case 0: do (* *to++ = *from++; case 7: do (* *to++ = *from++; case 6: do (* *to++ = *from++; case 5: do (* *to++ = *from++; case 4: do (* *to++ = *from++; case 3: do (* *to++ = *from++; case 2: do (* *to++ = *from++; case 1: do (* *to++ = *from++; while (–n»0); *) *) Зачем кто-то мог написать нечто похожее?
11. (*2) Напишите функцию atoi(), которая получает стрку, содержащую цифры, и возвращает соответствующее int. Наример, atoi(«123») – это 123. Модифицируйте atoi() так, чтобы помимо обычной десятичной она обрабатывала еще восьмеричную и шестнадцатиричную записи С++. Модифицируйте atoi() так, чтобы обрабатывать запись символьной константы. Напишите функцию itoa(), которая строит представление целого параметра в виде строки.
12. (*2) Перепишите get_token() (#3.1.2), чтобы она за один раз читала строку в буфер, а затем составляла лексемы, читая символы из буфера.
13. (*2) Добавьте в настольный калькулятор из #3.1 такие функции, как sqrt(), log() и sin(). Подсказка: предопределите имена и вызывайте функции с помощью вектора указателей на функции. Не забывайте проверять параметры в вызове функции.
14. (*3) Дайте пользователю возможность определять фунции в настольном калькуляторе. Подсказка: определяйте функции как последовательность действий, прямо так, как их набрал пользователь. Такую последовательность можно хранить или как символьную строку, или как список лексем. После этого, когда функция вызывается, читайте и выполняйте эти действия. Если вы хотите, чтобы пользовательская функция получала параметры, вы должны придумать форму записи этого.
15. (*1.5) Преобразуйте настольный калькулятор так, чтбы вместо статических переменных name_string и number_value использовалась структура символа symbol: struct symbol (* token_value tok; union (* double number_value; char* name_string; *); *);
16. (*2.5) Напишите программу, которая выбрасывает коментарии из С++ программы. То есть, читает из cin, удаляет // и /* */ комментарии и пишет результат в cout. Не заботьтесь о приятном виде выходного текста (это могло бы быть другим, блее сложным упражнением). Не беспокойтесь о правильности программ. Остерегайтесь // и /* и */ внутри комментариев, строк и символьных констант.
17. (*2) Посмотрите какие-нибудь программы, чтобы понять принцип различных стилей комментирования и выравнивания, кторые используются на практике.
2. (*1) Полностью расставьте скобки в следующих выражниях: a = b + c * d «« 2 amp; 8 a amp; 077 != 3 a == b !! a == c amp; amp; c « 5 c = x != 0 0 «= i « 7 f(1,2)+3 a = -1 + + b – – 5 a = b == c ++ a = b = c = 0 a[4][2] *= * b ? c : * d * 2 a-b,c=d
3. (*2) Найдите пять различных конструкций С++, значение которых неопределено.
4. (*2) Найдите десять различных примеров непереносимой С++ программы.
5. (*1) Что происходит в вашей системе, если вы делите на ноль? Что происходит при переполнении и потере значимости?
6. (*1) Полностью расставьте скобки в следующих выражниях: *p++ *–p ++a– (int*)p-»m *p.m *a[i]
7. (*2) Напишите функции: strlen(), которая возвращает длину строки, strcpy(), которая копирует одну строку в дргую, и strcmp(), которая сравнивает две строки. Разберитесь, какие должны быть типы параметров и типы возвращаемых значний, а потом сравните их со стандартными версиями, которые описаны в «string.h» и в вашем руководстве.
8. (*1) Посмотрите, как ваш компилятор реагирует на ошибки: a := b+1; if (a = 3) // ... if (a amp;077 == 0) // Придумайте ошибки попроще, и посмотрите, как компилятор на них реагирует.
9. (*2) Напишите функцию cat(), получающую два строковых параметра и возвращающую строку, которая является конкатенцией параметров. Используйте new, чтобы найти память для рзультата. Напишите функцию rev(), которая получает строку и переставляет в ней символы в обратном порядке. То есть, после вызова rev(p) последний символ p становится первым.
10. (*2) Что делает следующая программа?
void send(register* to, register* from, register count) // Полезные комментарии несомненно уничтожены. (* register n=(count+7)/8; switch (count%8) (* case 0: do (* *to++ = *from++; case 7: do (* *to++ = *from++; case 6: do (* *to++ = *from++; case 5: do (* *to++ = *from++; case 4: do (* *to++ = *from++; case 3: do (* *to++ = *from++; case 2: do (* *to++ = *from++; case 1: do (* *to++ = *from++; while (–n»0); *) *) Зачем кто-то мог написать нечто похожее?
11. (*2) Напишите функцию atoi(), которая получает стрку, содержащую цифры, и возвращает соответствующее int. Наример, atoi(«123») – это 123. Модифицируйте atoi() так, чтобы помимо обычной десятичной она обрабатывала еще восьмеричную и шестнадцатиричную записи С++. Модифицируйте atoi() так, чтобы обрабатывать запись символьной константы. Напишите функцию itoa(), которая строит представление целого параметра в виде строки.
12. (*2) Перепишите get_token() (#3.1.2), чтобы она за один раз читала строку в буфер, а затем составляла лексемы, читая символы из буфера.
13. (*2) Добавьте в настольный калькулятор из #3.1 такие функции, как sqrt(), log() и sin(). Подсказка: предопределите имена и вызывайте функции с помощью вектора указателей на функции. Не забывайте проверять параметры в вызове функции.
14. (*3) Дайте пользователю возможность определять фунции в настольном калькуляторе. Подсказка: определяйте функции как последовательность действий, прямо так, как их набрал пользователь. Такую последовательность можно хранить или как символьную строку, или как список лексем. После этого, когда функция вызывается, читайте и выполняйте эти действия. Если вы хотите, чтобы пользовательская функция получала параметры, вы должны придумать форму записи этого.
15. (*1.5) Преобразуйте настольный калькулятор так, чтбы вместо статических переменных name_string и number_value использовалась структура символа symbol: struct symbol (* token_value tok; union (* double number_value; char* name_string; *); *);
16. (*2.5) Напишите программу, которая выбрасывает коментарии из С++ программы. То есть, читает из cin, удаляет // и /* */ комментарии и пишет результат в cout. Не заботьтесь о приятном виде выходного текста (это могло бы быть другим, блее сложным упражнением). Не беспокойтесь о правильности программ. Остерегайтесь // и /* и */ внутри комментариев, строк и символьных констант.
17. (*2) Посмотрите какие-нибудь программы, чтобы понять принцип различных стилей комментирования и выравнивания, кторые используются на практике.
Глава 4 Функции и Файлы
Итерация свойственна человеку, рекурсия божественна.
Л. Питер Дойч
Все нетривиальные программы собираются из нескольких раздельно компилируемых единиц (их принято называть просто файлами). В этой главе описано, как раздельно откомпилированые функции могут обращаться друг к другу, как такие функции могут совместно пользоваться данными (разделять данные), и как можно обеспечить согласованность типов, которые использются в разных файлах программы. Функции обсуждаются довольно подробно. Сюда входят передача параметров, параметры по умочанию, перегрузка имен функций, и, конечно же, описание и оределение функций. В конце описываются макросы.
4.1 Введение
Иметь всю программу в одном файле обычно невозможно, поскольку коды стандартных библиотек и операционной системы находятся где-то в другом месте. Кроме того, хранить весь текст пользовательской программы в одном файле как правило непрактично и неудобно. Способ организации программы в файлы может помочь читающему охватить всю структуру программы, а также может дать возможность компилятору реализовать эту структуру. Поскольку единицей компиляции является файл, то во всех случаях, когда в файл вносится изменение (сколь бы мало оно ни было), весь файл нужно компилировать заново. Даже для программы умеренных размеров время, затрачиваемое на перекопиляцию, можно значительно снизить с помощью разбиения прораммы на файлы подходящих размеров.
Рассмотрим пример с калькулятором. Он был представлен в виде одного исходного файла. Если вы его набили, то у вас нверняка были небольшие трудности с расположением описаний в правильном порядке, и пришлось использовать по меньшей мере одно «фальшивое» описание, чтобы компилятор смог обработать взаимно рекурсивные функции expr(), term() и prim(). В тексте уже отмечалось, что программа состоит из четырех частей (лесического анализатора, программы синтаксического разбора, таблицы имен и драйвера), но это никак не было отражено в тексте самой программы. По сути дела, калькулятор был написан по-другому. Так это не делается; даже если в этой программе «на выброс» пренебречь всеми соображениями методологии прораммирования, эксплуатации и эффективности компиляции, автор все равно разобьет эту программу в 200 строк на несколько файлов, чтобы программировать было приятнее.
Программа, состоящая из нескольких раздельно компилирумых файлов, должна быть согласованной в смысле использования имен и типов, точно так же, как и программа, состоящая из оного исходного файла. В принципе, это может обеспечить и копоновщик*. Компоновщик – это программа, стыкующая отдельно скомпилированные части вместе. Компоновщик часто (путая) нзывают загрузчиком. В UNIX'е компоновщик называется ld. Однко компоновщики, имеющиеся в большинстве систем, обеспечивают очень слабую поддержку проверки согласованности.
– * или линкер. (прим. перев.)
Программист может скомпенсировать недостаток поддержки со стороны компоновщика, предоставив дополнительную информцию о типах (описания). После этого согласованность программы обеспечивается проверкой согласованности описаний, которые
находятся в отдельно компилируемых частях. Средства, которые это обеспечивают, в вашей системе будут. С++ разработан так, чтобы способствовать такой явной компоновке*.
– * C разработан так, чтобы в большинстве случаев позвлять осуществлять неявную компоновку. Применение C, однако, возросло неимоверно, поэтому случаи, когда можно использовать неявную линковку, сейчас составляют незначительное меньшинтво. (прим. автора)
Рассмотрим пример с калькулятором. Он был представлен в виде одного исходного файла. Если вы его набили, то у вас нверняка были небольшие трудности с расположением описаний в правильном порядке, и пришлось использовать по меньшей мере одно «фальшивое» описание, чтобы компилятор смог обработать взаимно рекурсивные функции 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 не могут быть частями одной С++ программы. Но если это так, то как же два файла могут использовать одни и те же типы и константы? Коротко, ответ таков: типы, константы и т.п. могут определяться столько раз, сколько нужно, при условии, что они определяются одинаково. Полный ответ несколько более сложен (это объясняется в следующем разделе).
// 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 «stream.h» //из стандартной директории включения #define «myheader.h» // из текущей директории
Использование «» имеет то преимущество, что в программу фактическое имя директории включения не встраивается (как правило, сначала просматривается /usr/include/CC, а потом usr /include). К сожалению, пробелы в директиве include сущесвенны:
#include « stream.h » // не найдет «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 «signal.h» Определения макросов #define Case break;case Комментарии /* проверка на конец файла */
но никогда
Определения обычных функций char get() (* return *p++; *) Определения данных int a;
Определения сложных константных объектов const tbl[]=(*/* ... */ *)
В системе UNIX принято, что заголовочные файлы имеют суффикс (расширение) .h. Файлы, содержащие определение данных или функций, должны иметь суффикс .c. Такие файлы часто назвают, соответственно, «.h файлы» и «.c файлы». В #4.7 описваются макросы. Следует заметить, что в С++ макросы гораздо менее полезны, чем в C, поскольку С++ имеет такие языковые конструкции, как const для определения констант и inline для исключения расходов на вызов функции.
Причина того, почему в заголовочных файлах допускается определение простых констант, но не допускается определение сложных константных объектов, прагматическая. В принципе, сложность тут только в том, чтобы сделать допустимым дублирвание определений переменных (даже определения функций можно было бы дублировать). Однако для компоновщиков старого обраца слишком трудно проверять тождественность нетривиальных констант и убирать ненужные повторы. Кроме того, простые слчаи гораздо более обиходны и потому более важны для генерации хорошего кода.
– * Легко изменить один компоновщик, но сделав это и напсав программу, которая зависит от усовершенствований, как вы будете переносить эту программу в другое место? (прим. автра)
Механизм включения с помощью #include – это чрезвычайно простое средство обработки текста для сборки кусков исходной программы в одну единицу (файл) для ее компиляции. Директива
#include «to_be_included»
замещает строку, в которой встретилось #include, содежимым файла «to_be_included». Его содержимым должен быть иходный текст на С++, поскольку дальше его будет читать комплятор. Часто включение обрабатывается отдельной программой, называемой C препроцессором, которую команда CC вызывает для преобразования исходного файла, который дал программист, в файл без директив включения перед тем, как начать собственно компиляцию. В другом варианте эти директивы обрабатывает итерфейсная система компилятора по мере того, как они встречются в исходном тексте. Если программист хочет посмотреть на результат директив включения, можно воспользоваться командой
CC -E file.c
для препроцессирования файла file.c точно также, как это сделала бы CC перед запуском собственно компилятора. Для включения файлов из стандартной директории включения вместо кавычек используются угловые скобки « и ». Например:
#include «stream.h» //из стандартной директории включения #define «myheader.h» // из текущей директории
Использование «» имеет то преимущество, что в программу фактическое имя директории включения не встраивается (как правило, сначала просматривается /usr/include/CC, а потом usr /include). К сожалению, пробелы в директиве include сущесвенны:
#include « stream.h » // не найдет «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 «signal.h» Определения макросов #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 «ctype.h»
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). В таких случаях не принято осуществлять чтение тысяч строк заголовоных файлов в начале каждой компиляции. Содержание этих файлов обычно «заморожено» и изменяется очень нечасто. Наиболее плезным может оказаться метод затравки компилятора содержанием этих заголовочных фалов. По сути, создается язык специального назначения со своим собственным компилятором. Никакого стадартного метода создания такого компилятора с затравкой не принято.
// 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 «ctype.h»
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() используется почти каждой функцией программы, а сама использует только «stream.h». Это обычная для функции ошибок ситуация, поэтому error() следует отделить от main():
// error.h: обработка ошибок
extern int no_errors;
extern double error(char* s);
// error.c
#include «stream.h» #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 «string.h» #include «table.h»
const TBLSZ = 23; name* table[TBLSZ];
name* look(char* p; int ins) (* /* ... */ *)
Заметьте, что описания функций работы со строками теперь включаются из «string.h». Это исключает еще один возможный источник ошибок.
// 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 «stream.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.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 «stream.h» #include «error.h» #include «lex.h» #include «syn.h» #include «table.h» #include «string.h»
main(int argc, char* argv[]) (* /* ... */ *)
Сколько заголовочных файлов использовать в программе, зависит от многих факторов. Многие из этих факторов сильнее связаны с тем, как ваша система работает с заголовочными фалами, нежели с С++. Например, если в вашем редакторе нет средств, позволяющих одновременно видеть несколько файлов, использование большого числа файлов становится менее привлкательным. Аналогично, если открывание и чтение 10 файлов по 50 строк в каждом требует заметно больше времени, чем чтение одного файла в 500 строк, вы можете дважды подумать, прежде чем использовать в небольшом проекте стиль множественных зголовочных файлов. Слово предостережения: набор из десяти зголовочных файлов плюс стандартные заголовочные файлы обычно легче поддаются управлению. С другой стороны, если вы разбили описания в большой программе на логически минимальные по рамеру заголовочные файлы (помещая каждое описание структуры в свой отдельный файл и т.д.), у вас легко может получиться нразбериха из сотен файлов.
Рассматривая организацию калькулятора, мы замечаем, что error() используется почти каждой функцией программы, а сама использует только «stream.h». Это обычная для функции ошибок ситуация, поэтому error() следует отделить от main():
// error.h: обработка ошибок
extern int no_errors;
extern double error(char* s);
// error.c
#include «stream.h» #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 «string.h» #include «table.h»
const TBLSZ = 23; name* table[TBLSZ];
name* look(char* p; int ins) (* /* ... */ *)
Заметьте, что описания функций работы со строками теперь включаются из «string.h». Это исключает еще один возможный источник ошибок.
// 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 «stream.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.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 «stream.h» #include «error.h» #include «lex.h» #include «syn.h» #include «table.h» #include «string.h»
main(int argc, char* argv[]) (* /* ... */ *)
Сколько заголовочных файлов использовать в программе, зависит от многих факторов. Многие из этих факторов сильнее связаны с тем, как ваша система работает с заголовочными фалами, нежели с С++. Например, если в вашем редакторе нет средств, позволяющих одновременно видеть несколько файлов, использование большого числа файлов становится менее привлкательным. Аналогично, если открывание и чтение 10 файлов по 50 строк в каждом требует заметно больше времени, чем чтение одного файла в 500 строк, вы можете дважды подумать, прежде чем использовать в небольшом проекте стиль множественных зголовочных файлов. Слово предостережения: набор из десяти зголовочных файлов плюс стандартные заголовочные файлы обычно легче поддаются управлению. С другой стороны, если вы разбили описания в большой программе на логически минимальные по рамеру заголовочные файлы (помещая каждое описание структуры в свой отдельный файл и т.д.), у вас легко может получиться нразбериха из сотен файлов.