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中，当我去编译时，我得到：“使用PBALL的源文件上的'newPBALL'的多个定义”错误以及ball.h中定义的函数。如何在没有遇到Linux中的这些问题的情况下让paddle.h了解PBALL？

我的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），我在两个头文件中都这样做了： / p>

#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大概是#includes“坏”头文件。而你得到编译错误。现在，只需预处理您的来源即可追踪它：

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

-E是在实际编译之前在预处理之后停止的选项。现在尝试编译预处理文件：

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

您应该发现与以前类似的错误。现在查看步骤2中bar.c中的预处理源，您可能更容易找到原因。首先只是搜索编译器抱怨的标识符 - 它实际上是多次声明的吗？如果是这样，为什么？可能在另一个标题中吗？或者也许某个地方的#define会弄乱你的名字？

在两个头文件中包含typedef

2 个答案: