Жанр: Учеба
Хрестоматия по программированию на Си в Unix
...кцию
сравнения до ее использования в qsort():
int cmp(...){ ... } /* реализация */
qsort(..... , cmp);
либо предварительно объявить имя функции сравнения, чтобы компилятор понимал, что это
именно функция:
int cmp();
qsort(..... , cmp);
int cmp(...){ ... } /* реализация */
1.138. Пусть у нас есть две программы, пользующиеся одной и той же структурой данных
W:
a.c b.c
-------------------------- ------------------------------
#include "fcntl.h" #include "fcntl.h"
struct W{ int x,y; }a; struct W{ int x,y; }b;
main(){ int fd; main(){ int fd;
a.x = 12; a.y = 77; fd = open("f", O_RDONLY);
fd = creat("f", 0644); read(fd, &b, sizeof b);
write(fd, &a, sizeof a); close(fd);
close(fd); printf("%d %d\n", b.x, b.y);
} }
Что будет, если мы изменим структуру на
struct W { long x,y; };
или
struct W { char c; int x,y; };
в файле a.c и забудем сделать это в b.c? Будут ли правильно работать эти программы?
Из наблюдаемого можно сделать вывод, что если две или несколько программ (или
частей одной программы), размещенные в разных файлах, используют общие
- типы данных (typedef);
- структуры и объединения;
- константы (определения #define);
- прототипы функций;
то их определения лучше выносить в общий include-файл (header-файл), дабы все программы
придерживались одних и тех же общих соглашений. Даже если эти соглашения со
А. Богатырев, 1992-95 - 70 - Си в UNIX
временем изменятся, то они изменятся во всех файлах синхронно и как бы сами собой. В
нашем случае исправлять определение структуры придется только в include-файле, а не
выискивать все места, где оно написано, ведь при этом немудрено какое-нибудь место и
пропустить!
W.h
-----------------------
struct W{ long x, y; };
a.c b.c
-------------------------- ------------------
#include "fcntl.h" #include "fcntl.h"
#include "W.h" #include "W.h"
struct W a; struct W b;
main(){ ... main(){ ...
printf("%ld...
Кроме того, вынесение общих фрагментов текста программы (определений структур, констант,
и.т.п.) в отдельный файл экономит наши силы и время - вместо того, чтобы набивать
один и тот же текст много раз в разных файлах, мы теперь пишем в каждом файле
единственную строку - директиву #include. Кроме того, экономится и место на диске,
ведь программа стала короче! Файлы включения имеют суффикс .h, что означает
"header-file" (файл-заголовок).
Синхронную перекомпиляцию всех программ в случае изменения include-файла можно
задать в файле Makefile - программе для координатора make[*]:
all: a b
echo Запуск a и b
a ; b
a: a.c W.h
cc a.c -o a
b: b.c W.h
cc b.c -o b
Правила make имеют вид
цель: список_целей_от_которых_зависит
команда
команда описывает что нужно сделать, чтобы изготовить файл цель из файлов
список_целей_от_которых_зависит. Команда выполняется только если файл цель еще не
существует, либо хоть один из файлов справа от двоеточия является более "молодым"
(свежим), чем целевой файл (смотри поле st_mtime и сисвызов stat в главе про UNIX).
1.139. Программа на Си может быть размещена в нескольких файлах. Каждый файл выступает
в роли "модуля", в котором собраны сходные по назначению функции и переменные.
Некоторые переменные и функции можно сделать невидимыми для других модулей. Для этого
надо объявить их static:
- Объявление переменной внутри функции как static делает переменную статической
(т.е. она будет сохранять свое значение при выходе из функции) и ограничивает ее
видимость пределами данной функции.
- Переменные, описанные вне функций, и так являются статическими (по классу
памяти). Однако слово static и в этом случае позволяет управлять видимостью этих
переменных - они будут видимы только в пределах данного файла.
- Функции, объявленные как static, также видимы только в пределах данного файла.
- Аргументы функции и локальные (автоматические) переменные функции и так сущест-
вуют только на время вызова данной функции (память для них выделяется в стеке
____________________
[*] Подробное описание make смотри в документации по системе UNIX.
А. Богатырев, 1992-95 - 71 - Си в UNIX
при входе в функцию и уничтожается при выходе) и видимы только внутри ее тела.
Аргументы функции нельзя объявлять static:
f(x) static x; { x++; }
незаконно.
Таким образом все переменные и функции в данном файле делятся на две группы:
- Видимые только внутри данного файла (локальные для модуля). Такие имена объяв-
ляются с использованием ключевого слова static. В частности есть еще "более
локальные" переменные - автоматические локалы функций и их формальные аргументы,
которые видимы только в пределах данной функции. Также видимы лишь в пределах
одной функции статические локальные переменные, объявленные в теле функции со
словом static.
- Видимые во всех файлах (глобальные имена).
Глобальные имена образуют интерфейс модуля и могут быть использованы в других модулях.
Локальные имена извне модуля недоступны.
Если мы используем в файле-модуле функции и переменные, входящие в интерфейс
другого файла-модуля, мы должны объявить их как extern ("внешние"). Для функций описатели
extern и int можно опускать:
// файл A.c
int x, y, z; // глобальные
char ss[200]; // глоб.
static int v, w; // локальные
static char *s, p[20]; // лок.
int f(){ ... } // глоб.
char *g(){ ... } // глоб.
static int h(){ ... } // лок.
static char *sf(){ ... } // лок.
int fi(){ ... } // глоб.
// файл B.c
extern int x, y;
extern z; // int можно опустить
extern char ss[]; // размер можно опустить
extern int f();
char *g(); // extern можно опустить
extern fi(); // int можно опустить
Хорошим тоном является написание комментария - из какого модуля или библиотеки импортируется
переменная или функция:
extern int x, y; /* import from A.c */
char *tgetstr(); /* import from termlib */
Следующая программа собирается из файлов A.c и B.c командой[**]
____________________
[**] Можно задать Makefile вида
CFLAGS = -O
AB: A.o B.o
cc A.o B.o -o AB
A.o: A.c
cc -c $(CFLAGS) A.c
B.o: B.c
cc -c $(CFLAGS) B.c
и собирать программу просто вызывая команду make.
А. Богатырев, 1992-95 - 72 - Си в UNIX
cc A.c B.c -o AB
Почему компилятор сообщает "x дважды определено"?
файл A.c файл B.c
-----------------------------------------
int x=12; int x=25;
main(){ f(y) int *y;
f(&x); {
printf("%d\n", x); *y += x;
} }
Ответ: потому, что в каждом файле описана глобальная переменная x. Надо в одном из
них (или в обоих сразу) сделать x локальным именем (исключить его из интерфейса
модуля):
static int x=...;
Почему в следующем примере компилятор сообщает "_f дважды определено"?
файл A.c файл B.c
----------------------------------------------------
int x; extern int x;
main(){ f(5); g(77); } g(n){ f(x+n); }
f(n) { x=n; } f(m){ printf("%d\n", m); }
Ответ: надо сделать в файле B.c функцию f локальной: static f(m)...
Хоть в одном файле должна быть определена функция main, вызываемая системой при
запуске программы. Если такой функции нигде нет - компилятор выдает сообщение "_main
неопределено". Функция main должна быть определена один раз! В файле она может находиться
в любом месте - не требуется, чтобы она была самой первой (или последней)
функцией файла[**].
1.140. В чем ошибка?
файл A.c файл B.c
----------------------------------------------------
extern int x; extern int x;
main(){ x=2; f(){
f(); printf("%d\n", x);
} }
Ответ: переменная x в обоих файлах объявлена как extern, в результате память для нее
нигде не выделена, т.е. x не определена ни в одном файле. Уберите одно из слов
extern!
1.141. В чем ошибка?
файл A.c файл B.c
----------------------------------------------------
int x; extern double x;
Типы переменных не совпадают. Большинство компиляторов не ловит такую ошибку, т.к.
каждый файл компилируется отдельно, независимо от остальных, а при "склейке" файлов в
____________________
[**] Если вы пользуетесь "новым" стилем объявления функций, но не используете прототипы,
то следует определять каждую функцию до первого места ее использования, чтобы
компилятору в точке вызова был известен ее заголовок. Это приведет к тому, что main()
окажется последней функцией в файле - ее не вызывает никто, зато она вызывает кого-то
еще.
А. Богатырев, 1992-95 - 73 - Си в UNIX
общую выполняемую программу компоновщик знает лишь имена переменных и функций, но не
их типы и прототипы. В результате программа нормально скомпилируется и соберется, но
результат ее выполнения будет непредсказуем! Поэтому объявления extern тоже полезно
выносить в include-файлы:
файл proto.h
------------------
extern int x;
файл A.c файл B.c
------------------ ------------------
#include "proto.h" #include "proto.h"
int x; ...
то, что переменная x в A.c оказывается описанной и как extern - вполне допустимо,
т.к. в момент настоящего объявления этой переменной это слово начнет просто игнорироваться
(лишь бы типы в объявлении с extern и без него совпадали - иначе ошибка!).
1.142. Что печатает программа и почему?
int a = 1; /* пример Bjarne Stroustrup-а */
void f(){
int b = 1;
static int c = 1;
printf("a=%d b=%d c=%d\n", a++, b++, c++);
}
void main(){
while(a " 4) f();
}
Ответ:
a=1 b=1 c=1
a=2 b=1 c=2
a=3 b=1 c=3
1.143. Автоматическая переменная видима только внутри блока, в котором она описана.
Что напечатает программа?
/* файл A.c */
int x=666; /*глоб.*/
main(){
f(3);
printf(" ::x = %d\n", x);
g(2); g(5);
printf(" ::x = %d\n", x);
}
g(n){
static int x=17; /*видима только в g*/
printf("g::x = %2d g::n = %d\n", x++, n);
if(n) g(n-1); else x = 0;
}
/* файл B.c */
extern x; /*глобал*/
f(n){ /*локал функции*/
x++; /*глобал*/
{ int x; /*локал блока*/
x = n+1; /*локал*/
А. Богатырев, 1992-95 - 74 - Си в UNIX
n = 2*x; /*локал*/
}
x = n-1; /*глобал*/
}
1.144. Функция, которая
- не содержит внутри себя статических переменных, хранящих состояние процесса
обработки данных (функция без "памяти");
- получает значения параметров только через свои аргументы (но не через глобальные
статические переменные);
- возвращает значения только через аргументы, либо как значение функции (через
return);
называется реентерабельной (повторно входимой) или чистой (pure). Такая функция
может параллельно (или псевдопараллельно) использоваться несколькими "потоками" обработки
информации в нашей программе, без какого-либо непредвиденного влияния этих
"потоков обработки" друг на друга. Первый пункт требований позволяет функции не
зависеть ни от какого конкретного процесса обработки данных, т.к. она не "помнит"
обработанных ею ранее данных и не строит свое поведение в зависимости от них. Вторые
два пункта - это требование, чтобы все без исключения пути передачи данных в функцию
и из нее (интерфейс функции) были перечислены в ее заголовке. Это лишает функцию
"побочных эффектов", не предусмотренных программистом при ее вызове (программист
обычно смотрит только на заголовок функции, и не выискивает "тайные" связи функции с
программой через глобальные переменные, если только это специально не оговорено).
Вот пример не реентерабельной функции:
FILE *fp; ... /* глобальный аргумент */
char delayedInput ()
{
static char prevchar; /* память */
char c;
c = prevchar;
prevchar = getc (fp);
return c;
}
А вот ее реентерабельный эквивалент:
char delayedInput (char *prevchar, FILE *fp)
{
char c;
c = *prevchar;
*prevchar = getc (fp);
return c;
}
/* вызов: */
FILE *fp1, *fp2; char prev1, prev2, c1, c2;
... x1 = delayedInput (&prev1, fp1);
x2 = delayedInput (&prev2, fp2); ...
Как видим, все "запоминающие" переменные (т.е. prevchar) вынесены из самой функции и
подаются в нее в виде аргумента.
Реентерабельные функции независимы от остальной части программы (их можно скопировать
в другой программный проект без изменений), более понятны (поскольку все затрагиваемые
ими внешние переменные перечислены как аргументы, не надо выискивать в
теле функции глобальных переменных, передающих значение в/из функции, т.е. эта функция
не имеет побочных влияний), более надежны (хотя бы потому, что компилятор в состоянии
проверить прототип такой функции и предупредить вас, если вы забыли задать
какой-то аргумент; если же аргументы передаются через глобальные переменные - вы
можете забыть проинициализировать какую-то из них). Старайтесь делать функции реентерабельными!
А. Богатырев, 1992-95 - 75 - Си в UNIX
Вот еще один пример на эту тему. Не-реентерабельный вариант:
int x, y, result;
int f (){
static int z = 4;
y = x + z; z = y - 1;
return x/2;
}
Вызов: x=13; result = f(); printf("%d\n", y);
А вот реентерабельный эквивалент:
int y, result, zmem = 4;
int f (/*IN*/ int x, /*OUT*/ int *ay, /*INOUT*/ int *az){
*az = (*ay = x + *az) - 1;
return x/2;
}
Вызов: result = f(13, &y, &zmem); printf("%d\n", y);
1.145. То, что формат заголовка функции должен быть известен компилятору до момента
ее использования, побуждает нас помещать определение функции до точки ее вызова. Так,
если main вызывает f, а f вызывает g, то в файле функции расположатся в порядке
g() { }
f() { ... g(); ... }
main(){ ... f(); ... }
Программа обычно разрабатывается "сверху-вниз" - от main к деталям. Си же вынуждает
нас размещать функции в программе в обратном порядке, и в итоге программа читается
снизу-вверх - от деталей к main, и читать ее следует от конца файла к началу!
Так мы вынуждены писать, чтобы удовлетворить Си-компилятор:
#include "stdio.h"
unsigned long g(unsigned char *s){
const int BITS = (sizeof(long) * 8);
unsigned long sum = 0;
for(;*s; s++){
sum ^= *s;
/* cyclic rotate left */
sum = (sum""1)|(sum""(BITS-1));
}
return sum;
}
void f(char *s){
printf("%s %lu\n", s, g((unsigned char *)s));
}
int main(int ac, char *av[]){
int i;
for(i=1; i " ac; i++)
f(av[i]);
return 0;
}
А вот как мы разрабатываем программу:
А. Богатырев, 1992-95 - 76 - Си в UNIX
#include "stdio.h"
int main(int ac, char *av[]){
int i;
for(i=1; i " ac; i++)
f(av[i]);
return 0;
}
void f(char *s){
printf("%s %lu\n", s, g((unsigned char *)s));
}
unsigned long g(unsigned char *s){
const int BITS = (sizeof(long) * 8);
unsigned long sum = 0;
for(;*s; s++){
sum ^= *s;
/* cyclic rotate left */
sum = (sum""1)|(sum""(BITS-1));
}
return sum;
}
и вот какую ругань производит Си-компилятор в ответ на эту программу:
"0000.c", line 10: identifier redeclared: f
current : function(pointer to char) returning void
previous: function() returning int : "0000.c", line 7
"0000.c", line 13: identifier redeclared: g
current : function(pointer to uchar) returning ulong
previous: function() returning int : "0000.c", line 11
Решением проблемы является - задать прототипы (объявления заголовков) всех функций в
начале файла (или даже вынести их в header-файл).
#include "stdio.h"
int main(int ac, char *av[]);
void f(char *s);
unsigned long g(unsigned char *s);
Тогда функции будет можно располагать в тексте в любом порядке.
1.146. Рассмотрим процесс сборки программы из нескольких файлов на языке Си. Пусть
мы имеем файлы file1.c, file2.c, file3.c (один из них должен содержать среди других
функций функцию main). Ключ компилятора -o заставляет создавать выполняемую программу
с именем, указанным после этого ключа. Если этот ключ не задан - будет создан
выполняемый файл a.out
cc file1.c file2.c file3.c -o file
Мы получили выполняемую программу file. Это эквивалентно 4-м командам:
cc -c file1.c получится file1.o
cc -c file2.c file2.o
cc -c file3.c file3.o
cc file1.o file2.o file3.o -o file
Ключ -c заставляет компилятор превратить файл на языке Си в "объектный" файл
А. Богатырев, 1992-95 - 77 - Си в UNIX
(содержащий машинные команды; не будем вдаваться в подробности). Четвертая команда
"склеивает" объектные файлы в единое целое - выполняемую программу[*]. При этом, если
какие-то функции, используемые в нашей программе, не были определены (т.е. спрограммированы
нами) ни в одном из наших файлов - будет просмотрена библиотека стандартных
функций. Если же каких-то функций не окажется и там - будет выдано сообщение об
ошибке.
Если у нас уже есть какие-то готовые объектные файлы, мы можем транслировать
только новые Си-файлы:
cc -c file4.c
cc file1.o file2.o file3.o file4.o -o file
или (что то же самое,
но cc сам разберется, что надо делать)
cc file1.o file2.o file3.o file4.c -o file
Существующие у нас объектные файлы с отлаженными функциями удобно собрать в библиотеку
- файл специальной структуры, содержащий все указанные файлы (все файлы склеены
в один длинный файл, разделяясь специальными заголовками, см. include-файл "ar.h"):
ar r file.a file1.o file2.o file3.o
Будет создана библиотека file.a, содержащая перечисленные .o файлы (имена библиотек в
UNIX имеют суффикс .a - от слова archive, архив). После этого можно использовать
библиотеку:
cc file4.o file5.o file.a -o file
Механизм таков: если в файлах file4.o и file5.o не определена какая-то функция (функции),
то просматривается библиотека, и в список файлов для "склейки" добавляется файл
из библиотеки, содержащий определение этой функции (из библиотеки он не удаляется!).
Тонкость: из библиотеки берутся не ВСЕ файлы, а лишь те, которые содержат определения
недостающих функций[**]. Если, в свою очередь, файлы, извлекаемые из библиотеки, будут
содержать неопределенные функции - библиотека (библиотеки) будут просмотрены еще раз
и.т.д. (на самом деле достаточно максимум двух проходов, так как при первом просмотре
библиотеки можно составить ее каталог: где какие функции в ней содержатся и кого
вызывают). Можно указывать и несколько библиотек:
cc file6.c file7.o \
file.a mylib.a /lib/libLIBR1.a -o file
Таким образом, в команде cc можно смешивать имена файлов: исходных текстов на Си .c,
объектных файлов .o и файлов-библиотек .a.
Просмотр библиотек, находящихся в стандартных местах (каталогах /lib и
/usr/lib), можно включить и еще одним способом: указав ключ -l. Если библиотека
называется
/lib/libLIBR1.a или /usr/lib/libLIBR2.a
то подключение делается ключами
-lLIBR1 и -lLIBR2
____________________
[*] На самом деле, для "склейки" объектных файлов в выполняемую программу, команда
/bin/cc вызывает программу /bin/ld - link editor, linker, редактор связей, компоновщик.
[**] Поэтому библиотека может быть очень большой, а к нашей программе "приклеится"
лишь небольшое число файлов из нее. В связи с этим стремятся делать файлы, помещаемые
в библиотеку, как можно меньше: 1 функция; либо "пачка" функций, вызывающих друг
друга.
А. Богатырев, 1992-95 - 78 - Си в UNIX
соответственно.
cc file1.c file2.c file3.o mylib.a -lLIBR1 -o file
Список библиотек и ключей -l должен идти после имен всех исходных .c и объектных .o
файлов.
Библиотека стандартных функций языка Си /lib/libc.a (ключ -lc) подключается
автоматически ("подключить" библиотеку - значит вынудить компилятор просматривать ее
при сборке, если какие-то функции, использованные вами, не были вами определены), то
есть просматривается всегда (именно эта библиотека содержит коды, например, для
printf, strcat, read).
Многие прикладные пакеты функций поставляются именно в виде библиотек. Такие
библиотеки состоят из ряда .o файлов, содержащих объектные коды для различных функций
(т.е. функции в скомпилированном виде). Исходные тексты от большинства библиотек не
поставляются (так как являются коммерческой тайной). Тем не менее, вы можете использовать
эти функции, так как вам предоставляются разработчиком:
- описание (документация).
- include-файлы, содержащие форматы данных используемые функциями библиотеки
(именно эти файлы включались #include в исходные тексты библ. функций. Теперь
уже вы должны включать их в свою программу).
Таким образом вы знаете, как надо вызывать библиотечные функции и какие структуры
данных вы должны использовать в своей программе для обращения к ним (хотя и не имеете
текстов самих библиотечных функций, т.е. не знаете, как они устроены. Например, вы
часто используете printf(), но задумываетесь ли вы о ее внутреннем устройстве?).
Некоторые библиотечные функции могут быть вообще написаны не на Си, а на ассемблере
или другом языке программирования[*][*]. Еще раз обращаю ваше внимание, что библиотека
содержит не исходные тексты функций, а скомпилированные коды (и include-файлы содержат
(как правило) не тексты функций, а только описание форматов данных)! Библиотека
может также содержать статические данные, вроде массивов строк-сообщений об ошибках.
Посмотреть список файлов, содержащихся в библиотеке, можно командой
ar tv имяФайлаБиблиотеки
а список имен функций - командой
nm имяФайлаБиблиотеки
Извлечь файл (файлы) из архива (скопировать его в текущий каталог), либо удалить его
из библиотеки можно командами
ar x имяФайлаБиблиотеки имяФайла1 ...
ar d имяФайлаБиблиотеки имяФайла1 ...
где ... означает список имен файлов.
"Лицом" библиотек служат прилагаемые к ним include-файлы. Системные includeфайлы,
содержащие общие форматы данных для стандартных библиотечных функций, хранятся
в каталоге /usr/include и подключаются так:
для /usr/include/файл.h надо #include "файл.h"
для /usr/include/sys/файл.h #include "sys/файл.h"
____________________
[*][*] Обратите внимание, что библиотечные функции не являются частью ЯЗЫКА Си как такового.
То, что в других языках (PL/1, Algol-68, Pascal) является частью языка
(встроено в язык)- в Си вынесено на уровень библиотек. Например, в Си нет оператора
вывода; функция вывода printf - это библиотечная функция (хотя и общепринятая). Таким
образом мощь языка Си состоит именно в том, что он позволяет использовать функции,
написанные другими программистами и даже на других языках, т.е. является функционально
расширяемым.
А. Богатырев, 1992-95 - 79 - Си в UNIX
(sys - это каталог, где описаны форматы данных, используемых ядром ОС и системными
вызовами). Ваши собственные include-файлы (посмотрите в предыдущий раздел!) ищутся в
текущем каталоге и включаются при помощи
#include "файл.h" /* ./файл.h */
#include "../h/файл.h" /* ../h/файл.h */
#include "/usr/my/файл.h" /* /usr/my/файл.h */
Непременно изучите содержимое стандартных include-файлов в своей системе!
В качестве резюме - схема, поясняющая "превращения" Си-программы из текста на
языке программирования в выполняемый код: все файлы .c могут использовать общие
include-файлы; их подстановку в текст, а также обработку #define произведет препроцессор
cpp
file1.c file2.c file3.c
| | | "препроцессор"
| cpp | cpp | cpp
| | | "компиляция"
| cc -c | cc -c | cc -c
| | |
file1.o file2.o file3.o
| | |
-----------*-----------
| Неявно добавятся:
ld |"----- /lib/libc.a (библ. станд. функций)
| /lib/crt0.o (стартер)
"связывание" |
"компоновка" |"----- Явно указанные библиотеки:
| -lm /lib/libm.a
V
a.out
1.147. Напоследок - простой, но жизненно важный совет. Если вы пишете программу,
которую вставите в систему для частого использования, поместите в исходный текст этой
программы идентификационную строку наподобие
static char id[] = "This is /usr/abs/mybin/xprogram";
Тогда в случае аварии в файловой системе, если вдруг ваш файл "потеряется" (то есть у
него пропадет имя - например из-за порчи каталога), то он будет найден программой
проверки файловой системы - fsck - и помещен в каталог /lost+found под специальным
кодовым именем, ничего общего не имеющим со старым. Чтобы понять, что это был за
файл и во что его следует переименовать (чтобы восстановить правильное имя), мы применим
команду
strings имя_файла
Эта команда покажет все длинные строки из печатных символов, содержащиеся в дан
...Закладка в соц.сетях
