Текст книги "Linux программирование в примерах"
Автор книги: Арнольд Роббинс
Жанры:
Программирование
,сообщить о нарушении
Текущая страница: 48 (всего у книги 55 страниц)
В общем, макросы препроцессора С являются довольно острой палкой с двумя концами. Они предоставляют вам большую мощь, но также и большую возможность пораниться самому.[169]169
Bjarne Stroustrup, создатель С++, настойчиво работал над тем, чтобы сделать использование препроцессора С совершенно ненужным в С++. По нашему мнению, он не вполне добился успеха: #include нужен до сих пор, но не обычные макросы. Для С препроцессор остается ценным и инструментом, но он должен использоваться благоразумно – Примеч. автора.
[Закрыть]
Обычно для эффективности или ясности можно видеть такие макросы:
#define RS_is_null (RS_node->var_value == Nnull_string)
...
if (RS_is_null || today == TUESDAY) ...
На первый взгляд, он выглядит замечательно. Условие 'RS_is_null' ясно и просто для понимания и абстрагирует внутренние детали проверки. Проблема возникает, когда вы пытаетесь вывести значение в GDB:
(gdb) print RS_is_null
No symbol "RS_is_null" in current context.
В таком случае нужно разыскать определение макроса и вывести развернутое значение.
Рекомендация: Для представления важных условий в своей программе используйте переменные, значения которых при изменении условий явным образом меняется в коде.
Вот сокращенный пример из io.c в дистрибутиве gawk:
void set_RS() {
...
RS_is_null = FALSE;
if (RS->stlen == 0) {
...
RS_is_null = TRUE;
...
matchrec = rsnullscan;
}
}
После установки и сохранения RS_is_null ее можно протестировать в коде и вывести из-под отладчика.
ЗАМЕЧАНИЕ. Начиная с GCC 3.1 и версии 5 GDB, если вы компилируете свою программу с опциями
-gdwarf-2и-g3, вы можете использовать макросы из-под GDB. В руководстве по GDB утверждается, что разработчики GDB надеются найти в конце концов более компактное представление для макросов, и что опция-g3будет отнесена к группе-g.Однако, использовать макросы таким способам позволяет лишь комбинация GCC, GDB и специальных опций: если вы не используете GCC (или если вы используете более старую версию), у вас все еще есть проблема. Мы придерживаемся своей рекомендации избегать по возможности таких макросов.
Проблема с макросами распространяется также и на фрагменты кода. Если макрос определяет несколько операторов, вы не можете установить контрольную точку в середине макроса. Это верно также для inline-функций C99 и С++: если компилятор заменяет тело inline-функции сгенерированным кодом, снова невозможно или трудно установить внутри него контрольную точку. Это имеет связь с нашим советом компилировать лишь с одной опцией -g; в этом случае компиляторы обычно не используют inline-функции.
Обычно с такими строками используется переменная, представляющая определенное состояние. Довольно просто, и это рекомендуется многими книгами по программированию на С, определять с помощью #define для таких состояний именованные константы. Например:
/* Различные состояния, в которых можно
находиться при поиске конца записи. */
#define NOSTATE 1 /* сканирование еще не началось (все) */
#define INLEADER 2 /* пропуск начальных данных (RS = "") */
#define INDATA 3 /* в теле записи (все) */
#define INTERM 4 /* терминатор сканирования (RS = RS = regexp) */
int state;
...
state = NOSTATE;
...
state = INLEADER;
...
if (state != INTERM) ...
На уровне исходного кода это выглядит замечательно. Но опять-таки, есть проблема, когда вы пытаетесь просмотреть код из GDB:
(gdb) print state
$1 = 2
Здесь вы также вынуждены возвращаться обратно и смотреть в заголовочный файл, чтобы выяснить, что означает 2. Какова же альтернатива?
Рекомендация: Для определения именованных констант используйте вместо макросов перечисления (enum). Использование исходного кода такое же, а значения enum может выводить также и отладчик.
Пример, тоже из io.c в gawk:
typedef enum scanstate {
NOSTATE, /* сканирование еще не начато (все) */
INLEADER, /* пропуск начальных данных (RS = "") */
INDATA, /* в теле записи (все) */
INTERM, /* терминатор сканирования (RS = "", RS = regexp) */
} SCANSTATE;
SCANSTATE state;
/* ... остальной код без изменений! ... */
Теперь при просмотре state из GDB мы видим что-то полезное:
(gdb) print state
$1 = NOSTATE
Довольно часто условие в if или while состоит из нескольких проверок, разделенных && или ||. Если эти проверки являются вызовами функций (или даже не являются ими), невозможно осуществить пошаговое прохождение каждой отдельной части условия. Команды GDB step и next работают на основе операторов (statements), а не выражений (expressions). (Разнесение их по нескольким строкам все равно не помогает).
Рекомендация: перепишите исходный код, явно используя временные переменные, в которых сохраняются значения или условные результаты, так что вы можете проверить их в отладчике. Первоначальный код должен быть сохранен в комментарии, чтобы вы (или программист после вас) могли сказать, что происходит.
Вот конкретный пример: функция do_input() из файла io.c gawk:
1 /* do_input – главный цикл обработки ввода */
2
3 void
4 do_input()
5 {
6 IOBUF *iop;
7 extern int exiting;
8 int rval1, rval2, rval3;
9
10 (void)setjmp(filebuf); /* for 'nextfile' */
11
12 while ((iop = nextfile(FALSE)) != NULL) {
13 /*
14 * Здесь было:
15 if (inrec(iop) == 0)
16 while (interpret(expression_value) && inrec(iop) == 0)
17 continue;
18 * Теперь развернуто для простоты отладки.
19 */
20 rvall = inrec(iop);
21 if (rvall == 0) {
22 for (;;) {
23 rval2 = rval3 = -1; /* для отладки */
24 rval2 = interpret(expression_value);
25 if (rval2 != 0)
26 rval3 = inrec(iop);
27 if (rval2 == 0 || rval3 != 0)
28 break;
29 }
30 }
31 if (exiting)
32 break;
33 }
34 }
(Номера строк приведены относительно начала этой процедуры, а не файла.) Эта функция является основой главного цикла обработки gawk. Внешний цикл (строки 12 и 33) проходит через файлы данных командной строки. Комментарий в строках 13–19 показывает оригинальный код, который читает из текущего файла каждую запись и обрабатывает ее
Возвращаемое inrec() значение 0 означает, что все в порядке, тогда как ненулевое возвращаемое значение interpret() означает, что все в порядке. Когда мы попытались пройти через этот цикл, проверяя процесс чтения записей, возникла необходимость выполнить каждый шаг отдельно.
Строки 20–30 представляют переписанный код, который вызывает каждую функцию отдельно, сохраняя возвращаемые значения в локальных переменных, чтобы их можно было напечатать из отладчика. Обратите внимание, как в строке 23 этим переменным каждый раз присваиваются известные, ошибочные значения: в противном случае они могли бы сохранить свои значения от предыдущих итераций цикла. Строка 27 является тестом завершения, поскольку код изменился, превратившись в бесконечный цикл (сравните строку 22 со строкой 16), тест завершения цикла является противоположным первоначальному.
В качестве отступления, мы признаемся, что нам пришлось тщательно изучить переделку, когда мы ее сделали, чтобы убедиться, что она точно соответствует первоначальному коду; она соответствовала. Теперь нам кажется, что, возможно, вот эта версия цикла была бы ближе к оригиналу:
/* Возможная замена для строк 22 – 29 */
do {
rval2 = rval3 = -1; /* для отладки */
rval2 = interpret(expression_value);
if (rval2 != 0)
rval3 = inrec(iop);
} while (rval2 != 0 && rval3 == 0);
Правда в том, что обе версии труднее воспринимать, чем оригинал, и поэтому, возможно, содержат ошибки. Однако, поскольку текущий код работает, мы решили оставить как есть.
Наконец, мы обращаем внимание, что не все программисты-эксперты согласились бы здесь с нашим советом. Когда каждый компонент условия является вызовом функции, можно установить на каждую контрольную точку, использовать step для входа в каждую функцию, а затем использовать finish для ее завершения. GDB сообщит вам возвращаемое функцией значение, и с этого места вы можете использовать для продолжения cont или step. Нам нравится наш подход, поскольку результаты сохраняются в переменных, которые можно проверить (и неоднократно) после вызова функции и даже спустя несколько операторов.
Типичной методикой, применимой во многих случаях, является использование набора значений флагов; когда флаг установлен (т.е. равен true), имеет место определенный факт или применяется определенное условие. Обычно это осуществляется при помощи именованных констант #define и битовых операторов С. (Использование битовых флагов и операторы работы с битами мы обсуждали во врезке к разделу 8.3.1 «Стиль POSIX: statvfs() и fstatvfs()».)
Например, главная структура данных gawk называется NODE. У нее большое количество полей, последнее из которых является набором значений флагов. Из файла awk.h:
typedef struct exp_node {
/* ... Куча материала опущена */
unsigned short flags;
#define MALLOC 1 /* может быть освобожден */
#define TEMP 2 /* должен быть освобожден */
#define PERM 4 /* не может быть освобожден */
#define STRING 8 /* назначен в виде строки */
#define STRCUR 16 /* текущее значение строковое */
#define NUMCUR 32 /* текущее значение числовое */
#define NUMBER 64 /* назначен в виде числа */
#define MAYBE_NUM 128 /* ввод пользователя: если NUMERIC, тогда
* NUMBER */
#define ARRAYMAXED 256 /* размер массива максимальный */
#define FUNC 512 /* параметр представляет имя функции;
* см. awkgram.y */
#define FIELD 1024 /* это является полем */
#define INTLSTR 2048 /* использовать локализованную версию */
} NODE;
Причина для использования значений флагов заключается в том, что они значительно экономят пространство данных. Если бы структура NODE для каждого флага использовала отдельное поле char, потребовалось бы 12 байтов вместо 2, используемых unsigned short. Текущий размер NODE (на Intel x86) 32 байта. Добавление лишних 10 байтов увеличило бы ее до 42 байтов. Поскольку gawk может потенциально выделять сотни и тысячи (или даже миллионы) NODE[170]170
Серьезно! Часто люди пропускают через gawk мегабайты данных. Помните, никаких произвольных ограничений! – Примеч. автора.
[Закрыть], сохранение незначительного размера является важным.
Что это должно делать с отладкой? Разве мы не рекомендовали только что использовать для именованных констант enum? Ну, в случае объединяемых побитовыми ИЛИ значений enum не помогают, поскольку они больше не являются индивидуально распознаваемыми!
Рекомендация: предусмотрите функцию для преобразования флагов в строки. Если у вас есть несколько независимых флагов, установите процедуру общего назначения.
ЗАМЕЧАНИЕ. Необычность этих функций отладки заключается в том, что код приложения никогда их не вызывает. Они существуют лишь для того, чтобы их можно было вызывать из отладчика. Такие функции всегда должны быть откомпилированы с кодом, даже без окружающих
#ifdef, чтобы их можно было использовать. не предпринимая никаких дополнительных шагов. Увеличение (обычно минимальное) размера кода оправдывается экономией времени разработчика
Сначала мы покажем вам, как мы это делали первоначально. Вот (сокращенная версия) flags2str() из ранней версии gawk (3.0.6):
1 /* flags2str – делает значения флагов удобочитаемыми */
2
3 char *
4 flags2str(flagval)
5 int flagval;
6 {
7 static char buffer[BUFSIZ];
8 char *sp;
9
10 sp = buffer;
11
12 if (flagval & MALLOC) {
13 strcpy(sp, "MALLOC");
14 sp += strlen(sp);
15 }
16 if (flagval & TEMP) {
17 if (sp >= buffer)
18 *sp++ = '|';
19 strcpy(sp, "TEMP");
20 sp += strlen(sp);
21 }
22 if (flagval & PERM) {
23 if (sp != buffer)
24 *sp++ = '|';
25 strcpy(sp, "PERM");
26 sp += strlen(sp);
27 }
/* ...многое то же самое, опущено для краткости... */
82
83 return buffer;
84 }
(Номера строк даны относительно начала функции.) Результатом является строка, что– то наподобие "MALLOC | PERM | NUMBER". Каждый флаг тестируется отдельно, и если он присутствует, действие каждый раз одно и то же: проверка того, что он не в начале буфера и что можно добавить символ '|', скопировать строку на место и обновить указатель. Сходные функции существовали для форматирования и отображения других видов флагов в программе.
Этот код является повторяющимся и склонным к ошибкам, и для gawk 3.1 мы смогли упростить и обобщить его. Вот как gawk делает это сейчас. Начиная с этого определения в awk.h:
/* для целей отладки */
struct flagtab {
int val; /* Целое значение флага */
const char *name; /* Строковое имя */
};
Эту структуру можно использовать для представления любого набора флагов с соответствующими строковыми значениями. Каждая отдельная группа флагов имеет соответствующую функцию, которая возвращает печатное представление флагов, которые установлены в настоящее время. Из eval.c:
/* flags2str – делает значения флагов удобочитаемыми */
const char *flags2str(int flagval) {
static const struct flagtab values[] = {
{ MALLOC, "MALLOC" },
{ TEMP, "TEMP" },
{ PERM, "PERM" },
{ STRING, "STRING" },
{ STRCUR, "STRCUR" },
{ NUMCUR, "NUMCUR" },
{ NUMBER, "NUMBER" },
{ MAYBE_NUM, "MAYBE_NUM" },
{ ARRAYMAXED, "ARRAYMAXED" },
{ FUNC, "FUNC" },
{ FIELD, "FIELD" },
{ INTLSTR, "INTLSTR" },
{ 0, NULL },
};
return genflags2str(flagval, values);
}
flags2str() определяет массив сопоставлений флагов со строками. По соглашению, значение флага 0 означает конец массива. Код вызывает для осуществления работы genflags2str() («общий флаг в строку»). getflags2str() является процедурой общего назначения, которая преобразует значение флага в строку. Из eval.c:
1 /* genflags2str – общая процедура для преобразования значения флага в строковое представление */
2
3 const char *
4 genflags2str(int flagval, const struct flagtab *tab)
5 {
6 static char buffer(BUFSIZ];
7 char *sp;
8 int i, space_left, space_needed;
9
10 sp = buffer;
11 space_left = BUFSIZ;
12 for (i = 0; tab[i].name != NULL; i++) {
13 if ((flagval & tab[i].val) != 0) {
14 /*
15 * обратите внимание на уловку, нам нужны 1 или 0, чтобы
16 * определить, нужен ли нам символ '|'.
17 */
18 space_needed = (strlen(tab[i].name) + (sp != buffer));
19 if (space_left < space_needed)
20 fatal(_("buffer overflow in genflags2str"));
21
22 if (sp >= buffer) {
23 *sp++ = '|';
24 space_left–;
25 }
26 strcpy(sp, tab[i].name);
27 /* обратите внимание на расположение! */
28 space_left -= strlen(sp);
29 sp += strlen(sp);
30 }
31 }
32
33 return buffer;
34 }
(Номера строк приведены относительно начала функции, а не файла.) Как и в предыдущей версии, идея заключалась в заполнении статического буфера строковыми значениями, такими, как "MALLOC | PERM | STRING | MAYBE_NUM", и возвращении адреса этого буфера. Мы вскоре обсудим причины использования статического буфера; сначала давайте исследуем код.
Указатель sp отслеживает положение следующего пустого слота в буфере, тогда как space_left отслеживает количество оставшегося места; это уберегает нас от переполнения буфера.
Основную часть функции составляет цикл (строка 12), проходящий через массив значений флагов. Когда флаг найден (строка 13), код вычисляет, сколько места требуется строке (строка 18) и проверяет, осталось ли столько места (строки 19–20).
Тест 'sp ! = buffer' для первого значения флага завершается неудачей, возвращая 0. Для последующих флагов тест дает значение 1. Это говорит нам, что между значениями должен быть вставлен разделительный символ '|'. Добавляя результат (1 или 0) к длине строки, мы получаем правильное значение space_needed. Тот же тест с той же целью проводится в строке 22 для проверки строк 23 и 24, которые вставляют символ '|'.
В заключение строки 26–29 копируют значение строки, выверяют количество оставшегося места и обновляют указатель sp. Строка 33 возвращает адрес буфера, который содержит печатное представление строки.
Теперь несколько слов относительно статического буфера. Обычно хорошая практика программирования не одобряет использование функций, возвращающих адреса статических буферов: множественные вызовы таких функций каждый раз переписывают буфер, вынуждая вызывающего копировать возвращенные данные.
Более того, статический буфер по определению является буфером фиксированного размера. Что случилось с принципом GNU «никаких произвольных ограничений»?
Для ответа на эти вопросы нужно вспомнить, что это отладочная функция. Обычный код никогда не вызывает getflags2str(); она вызывается лишь человеком, использующим отладчик. Ни у одного вызывающего нет указателя на буфер; как разработчику, осуществляющему отладку, нам нет дела до того, что буфер каждый раз переписывается при вызове функции.
На практике фиксированный размер также не является проблемой; мы знаем, что размер BUFSIZ достаточен для представления всех флагов, которые мы используем. Тем не менее, поскольку мы опытные и знаем, что вещи могут измениться, в getflags2str() есть код, предохраняющий себя от переполнения буфера. (Переменная space_left и код в строках 18–20.)
В качестве отступления, использование BUFSIZ спорно. Эта константа должна использоваться исключительно для буферов ввода/вывода, но часто она используется также для общих строковых буферов. Такой код лучше убрать, определив явные константы, такие, как FLAGVALSIZE, и использовав в строке 11 'sizeof (buffer)'.
Вот сокращенный сеанс GDB, показывающий использование flags2str():
$ gdb gawk /* Запустить GDB с gawk */
GNU gdb 5.3
...
(gdb) break do_print /* Установить контрольную точку */
Breakpoint 1 at 0x805a584: file builtin.c, line 1547.
(gdb) run 'BEGIN { print "hello, world" }' /* Запустить программу */
Starting program: /home/arnold/Gnu/gawk/gawk-3.1.4/gawk 'BEGIN { print "hello, world" }'
Breakpoint 1, do_print (tree=0x80955b8) at builtin.c: 1547 /* Останова в контрольной точке */
1547 struct redirect *rp = NULL;
(gdb) print *tree /* Вывести NODE */
$1 = {sub = {nodep =
{1 = {lptr = 0x8095598, param_name = 0x8095598 "xUtb",
ll = 134629464}, r = {rptr = 0x0, pptr = 0, preg = 0x0, hd = 0x0,
av = 0x0, r_ent =0}, x = {extra = 0x0, xl = 0, param_list = 0x0},
name = 0x0, number = 1, reflags = 0), val = {
fltnum = 6.6614606209589101e-316, sp = 0x0, slen = 0, sref = 1,
idx = 0}, hash = {next = 0x8095598, name = 0x0, length = 0, value = 0x0,
ref = 1}}, type = Node_K_print, flags = 1}
(gdb) print flags2str(tree->flags) /* Вывести значение флага */
$2 = 0x80918a0 "MALLOC"
(gdb) next /* Продолжить */
1553 fp = redirect_to_fp(tree->rnode, &rp);
...
1588 efwrite(t[i]->stptr, sizeof(char), t[i]->stlen, fp, "print", rp, FALSE);
(gdb) print *t[i] /* Снова вывести NODE */
$4 = {sub = {nodep =
{l = {lptr = 0x8095598, parm_name = 0x8095598 "xUtb",
ll = 134829464}, r = {rptr = 0x0, pptr = 0, preg = 0x0, hd = 0x0,
av = 0x0, r_ent =0), x = {extra = 0x8095ad8, xl = 134830808,
param_list = 0x8095ad8}, name = 0xc ,
number = 1, reflags = 4294967295}, val = {
fltnum = 6.6614606209589101e-316, sp = 0x8095ad8 "hello, world",
slen = 12, sref = 1, idx = -1}, hash = {next = 0x8095598, name = 0x0,
length = 134830808, value = 0xc, ref = 1}}, type = Node_val, flags = 29}
(gdb) print flags2str(t[i]->flags) /* Вывести значение флага */
$5 = 0x80918a0 "MALLOC|PERM|STRING|STRCUR"
Надеемся, вы согласитесь, что настоящий механизм общего назначения значительно более элегантный и более простой в использовании, чем первоначальный.
Тщательное проектирование и использование массивов структур часто может заменить или слить воедино повторяющийся код.
«Не бывает бесплатных обедов»
– Lazarus Long -
union С относительно эзотерическая возможность. Она помогает экономить память, сохраняя различные элементы в одном и том же физическом пространстве; как программа интерпретирует его, зависит от способа доступа:
/* ch15-union.c – краткая демонстрация использования union. */
#include
int main(void) {
union i_f {
int i;
float f;
} u;
u.f = 12.34; /* Присвоить значение с плавающей точкой */
printf("%f also looks like %#xn", u.f, u.i};
exit(0);
}
Вот что происходит, когда программа запускается на системе Intel x86 GNU/Linux:
$ ch15-union
12.340000 also looks like 0x414570a4
Программа выводит битовый паттерн, который представляет число с плавающей точкой в виде шестнадцатеричного целого. Оба поля занимают одно и то же место в памяти; разница в том, как этот участок памяти интерпретируется: u.f действует, как число с плавающей точкой, тогда как эти же биты в u.i действуют, как целое число.
Объединения особенно полезны в компиляторах и интерпретаторах, которые часто создают древовидные структуры, представляющие структуру файла с исходным кодом (которая называется деревом грамматического разбора (parse tree)). Это моделирует то, как формально описаны языки программирования: операторы if, операторы while, операторы присваивания и так далее для всех экземпляров более общего типа «оператора». Таким образом, в компиляторе могло бы быть нечто подобное этому:
struct if_stmt { ... }; /* Структура для оператора IF */
struct while_stmt { ... }; /* Структура для оператора WHILE */
struct for_stmt { ... }; /* Структура для оператора */
/* ...структуры для других типов операторов... */
typedef enum stmt_type {
IF, WHILE, FOR, ...
} TYPE; /* Что у нас есть в действительности */
/* Здесь содержатся тип и объединения отдельных видов операторов. */
struct statement {
TYPE type;
union stmt {
struct if_stmt if_st;
struct while_stmt while_st;
struct for_stmt for_st;
...
} u;
};
Вместе с объединением удобно использовать макрос, который представляет компоненты объединения, как если бы они были полями структуры. Например:
#define if_s u.if_st /* Так что можно использовать s->if_s вместо s->u.if_st */
#define while_s u.while_st /* И так далее... */
#define for_s u.for_st
...
На только что представленном уровне это кажется разумным и выглядит осуществимым. В действительности, однако, все сложнее, и в реальных компиляторах и интерпретаторах часто есть несколько уровней вложенных структур и объединений. Сюда относится и gawk, в котором определение NODE, значение его флагов и макросов для доступа к компонентам объединения занимают свыше 120 строк![171]171
Мы унаследовали эту схему. В общем, она работает, но все же есть проблемы. Целью данного раздела является передача накопленного нами в ходе работы с объединениями опыта – Примеч. автора.
[Закрыть] Здесь достаточно определений, чтобы дать вам представление о том, что происходит:
typedef struct exp_node {
union {
struct {
union {
struct exp_node *lptr;
char *param_name;
long ll;
} l;
union {
...
} r;
union {
...
} x;
char *name;
short number;
unsigned long reflags;
...
} nodep;
struct {
AWKNUM fltnum;
char *sp;
size_t slen;
long sref;
int idx;
} val;
struct {
struct exp_node *next;
char *name;
size_t length;
struct exp_node *value;
long ref;
} hash;
#define hnext sub.hash.next
#define hname sub.hash.name
#define hlength sub.hash.length
#define hvalue sub.hash.value
...
} sub;
NODETYPE type;
unsigned short flags;
...
} NODE;
#define vname sub.nodep.name
#define exec_count sub.nodep.reflags
#define lnode sub.nodep.l.lptr
#define nextp sub.nodep.l.lptr
#define source_file sub.nodep.name
#define source_line sub.nodep.number
#define param_cnt sub.nodep.number
#define param sub.nodep.l.param_name
#define stptr sub.val.sp
#define stlen sub.val.slen
#define stref sub.val.sref
#define stfmt sub.val.idx
#define var_value lnode
...
В NODE есть объединение внутри структуры внутри объединения внутри структуры! (Ой.) Поверх всего этого многочисленные «поля» макросов соответствуют одним и тем же компонентам struct/union в зависимости от того, что на самом деле хранится в NODE! (Снова ой.)
Преимуществом такой сложности является то, что код С сравнительно ясный. Нечто вроде 'NF_node->var_value->slen' читать просто.
У такой гибкости, которую предоставляют объединения, конечно, есть своя цена. Когда отладчик находится глубоко во внутренностях вашего кода, вы не можете использовать симпатичные макросы, которые имеются в исходном коде. Вы должны использовать развернутое значение.[172]172
Опять-таки, GCC 3.1 или более новый и GDB 5 дают возможность непосредственного использования макросов, но только лишь если вы используете их совместно, с определенными опциями. Это было описано ранее в разделе 15.4.1.2 «По возможности избегайте макросов с выражениями». – Примеч. автора.
[Закрыть] (А для этого придется найти в заголовочном файле соответствующее определение.)
Например, сравните 'NF_node->var_value->slen' с развернутой формой: 'NF_node->sub.nodep.l.lptr->sub.val.slen'! Чтобы увидеть значение данных, вы должны набрать последнее в GDB. Взгляните снова на это извлечение из приведенного ранее сеанса отладки GDB:
(gdb) print *tree /* Вывести NODE */
$1 = {sub = {nodep =
{1 = {lptr = 0x8095598, param_name = 0x8095598 "xUtb",
ll = 134829464}, r = {rptr = 0x0, pptr = 0, preg = 0x0,
hd = 0x0, av = 0x0, r_ent =0), x = {extra = 0x0, xl = 0,
param_list = 0x0}, name = 0x0, number = 1, reflags = 0},
val = { fltnum = 6.6614606209589101e-316, sp = 0x0,
slen = 0, sref = 1, idx = 0),
hash = {next = 0x8095598, name = 0x0, length = 0,
value = 0x0, ref = 1}}, type = Node_K_print, flags = 1}
Это куча вязкой массы. Однако, GDB все же несколько упрощает ее обработку. Вы можете использовать выражения вроде '($1).sub.val.slen', чтобы пройти через дерево и перечислить структуры данных.
Есть другие причины для избегания объединений. Прежде всего, объединения не проверяются. Ничто, кроме внимания программиста, не гарантирует, что когда вы получаете доступ к одной части объединения, вы получаете доступ к той части, которая была сохранена последней. Мы видели это в ch15-union.c, в котором доступ к обоим «элементам» объединения осуществлялся одновременно.
Вторая причина, связанная с первой, заключается в осторожности с перекрытиями вложенных комбинаций struct/union. Например, в предыдущей версии gawk[173]173
Эта часть кода была с тех пор пересмотрена, поэтому там больше нет этих строк из примера. – Примеч. автора.
[Закрыть] был такой код.
/* n->lnode перекрывает размер массива, не вызывайте unref, если это массив */
if (n->type != Node_var_array && n->type != Node_array_ref)
unref(n->lnode);
Первоначально if не было, был только вызов unref(), которая освобождает NODE, на которую указывает n->lnode. Однако, в этот момент gawk могла создать аварийную ситуацию. Можете себе представить, сколько времени потребовало отслеживание в отладчике того факта, что то, что рассматривалось как указатель, на самом деле было размером массива!
В качестве отступления, объединения значительно менее полезны в С++. Наследование и объектно-ориентированные возможности создают при управлении структурами данных совсем другую ситуацию, которая значительно безопаснее.
Рекомендация: по возможности избегайте объединений (union). Если это невозможно, тщательно проектируйте и программируйте их!
