Включая ЬурейеЕ в двух заголовочных файлах

Question

у меня есть это в 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, потому что это Безразлично Не знаю о PBALL. Поэтому, если я добавлю:

#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; 
} 

Answer 1

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

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

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

Answer 2

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

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

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, которая возится с вашими именами?