Включение typedef в два заголовочных файла - PullRequest
3 голосов
/ 01 апреля 2012

У меня есть это в ball.h:

#ifndef BALL_H_
#define BALL_H_
...
typedef void *PBALL  ;
...
#endif

в paddle.h У меня есть:

#ifndef PADDLE_H_
#define PADDLE_H_
...
int contact_made(struct pppaddle*, PBALL);
...
#endif

Я получаю ошибку в paddle.h, потому что он не знаето ПБАЛЛ.Поэтому, если я добавлю:

#ifndef BALL_H_
#include    "ball.h"
#endif

в paddle.h (с оператором if или без него), он будет работать в моей среде Cygwin.Но в Linux, когда я иду к компиляции, я получаю: «множественное определение` newPBALL '»в исходном файле, который использует PBALL, а также в функциях, определенных в ball.h.Как я могу получить paddle.h для понимания PBALL, не сталкиваясь с этими проблемами в Linux?

Мой файл ball.c:

struct newball {
    int x_pos, x_dir, y_pos, y_dir, y_delay, y_count, x_delay, x_count;
    char symbol;
};

typedef struct newball *ball_struct_ptr;
struct newball the_ball;

#include "ball.h"

PBALL newPBALL() {

    the_ball.y_pos = Y_INIT;
    the_ball.x_pos = X_INIT;
    the_ball.y_count = the_ball.y_delay = Y_DELAY;
    the_ball.x_count = the_ball.x_delay = X_DELAY;
    the_ball.y_dir = 1;
    the_ball.x_dir = 1;

    the_ball.symbol = DFL_SYMBOL;       //Set the symbol of the ball

    PBALL ptr = &the_ball;
    return ptr;
}

Ответы [ 2 ]

3 голосов
/ 02 апреля 2012

Ну, вместо того, чтобы пытаться импортировать один заголовочный файл в другой (который работал в Cygwin, но не в Linux) или не импортировать заголовок в другой заголовок (который работал для Linux, но не в Cygwin), я сделал это в обоих заголовочных файлах:

#ifndef TYPEDEF_PBALL_DECLARED_
#define TYPEDEF_PBALL_DECLARED_
typedef void *PBALL  ;
#endif

Теперь он работает в обеих средах. Я оставлю это открытым на некоторое время, в случае, если есть лучшее решение, чем необходимость дважды объявлять typedef в двух заголовочных файлах.

0 голосов
/ 01 апреля 2012

Я не знаю, в чем именно проблема, но я мог бы рассказать вам, как ее решить.

Создайте свою программу как обычно. Захватите командную строку неудачного этапа компиляции. Это может быть что-то вроде:

gcc -c -o foo/bar.o baz.c

Таким образом, baz.c предположительно # включает «плохие» заголовочные файлы. И вы получите ошибку компиляции. Теперь отследите его, просто предварительно обработав ваши источники:

gcc -E -o foo/bar.c baz.c

-E - опция остановки после предварительной обработки перед фактической компиляцией. Теперь попробуйте скомпилировать предварительно обработанный файл:

gcc -c -o foo/bar.o bar.c

Вы должны найти такую ​​же ошибку, как и раньше. Теперь посмотрите на предварительно обработанный источник в bar.c из шага 2, и вам может быть легче найти причину. Начните с простого поиска идентификатора, на который жалуется компилятор - действительно ли он объявлен несколько раз? Если так, то почему? Может ли это быть в другом заголовке? Или, может быть, где-то есть #define, который смешивается с вашими именами?

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...