如何在通用标头中 typedef 实现定义的结构？

我有一个 C 项目，旨在可移植到各种（PC 和嵌入式）平台。

应用程序代码将使用具有特定于平台的实现的各种调用，但共享通用（通用）API 以帮助实现可移植性。我正在尝试确定声明函数原型和结构的最合适方法。

到目前为止，这是我想到的：

main.c:

#include "generic.h"

int main (int argc, char *argv[]) {
    int  ret;
    gen_t  *data;

    ret = foo(data);
    ...
}

通用.h：（与平台无关的包括）

typedef struct impl_t gen_t;

int foo (gen_t *data);

impl.h:（特定于平台的声明）

#include "generic.h"

typedef struct impl_t {
    /* ... */
} gen_t;

impl.c:（特定于平台的实现）

int foo (gen_t *data) {
    ...
}

Build:

gcc -c -fPIC -o platform.o impl.c
gcc -o app  main.c platform.o

现在，这似乎有效......因为它编译正常。但是，我通常不会标记我的结构，因为它们永远不会在外部访问typedef倒是别名。这是一个小问题，但我想知道是否有办法用匿名结构达到相同的效果？

我也要求后代，因为我搜索了一段时间，我找到的最接近的答案是：（Link https://stackoverflow.com/questions/9749943/how-to-make-a-structure-extern-and-define-its-typedef)

就我而言，这不是正确的方法，因为应用程序特别不应该直接包含实现标头——重点是将程序与平台分离。

我看到了其他一些不太理想的方法来解决这个问题，例如：

通用.h：

#ifdef PLATFORM_X
#include "platform_x/impl.h"
#endif

/* or */

int foo (struct impl_t *data);

这些似乎都不是特别吸引人，而且绝对不是我的风格。虽然我不想逆流而上，但当可能有更好的方法来准确实现我的想法时，我也不希望出现冲突的风格。所以我认为 typedef 解决方案走在正确的轨道上，它只是我留下的结构标签包袱。

想法？

您当前的技术是正确的。尝试使用匿名（未标记）struct失败了你想要做的事情 - 你必须暴露定义的细节struct无处不在，这意味着您不再拥有不透明的数据类型。

In a comment https://stackoverflow.com/questions/26813097/how-do-i-typedef-an-implementation-defined-struct-in-a-generic-header/26814210?noredirect=1#comment42202359_26814210, 用户3629249 https://stackoverflow.com/users/3629249/user3629249 said:

头文件包含的顺序意味着存在对结构体的前向引用generic.h文件;也就是说，在定义结构之前，就使用它。这不太可能编译。

对于问题中显示的标题，此观察结果是不正确的；对于样本来说是准确的main()代码（在添加此响应之前我没有注意到）。

关键点是所示的接口函数接受或返回指向类型的指针gen_t，这又映射到struct impl_t指针。只要客户端代码不需要为该结构分配空间，或者取消引用指向结构的指针来访问该结构的成员，客户端代码就不需要知道该结构的详细信息。将结构类型声明为现有就足够了。您可以使用其中任何一个来声明struct impl_t:

struct impl_t;

typedef struct impl_t gen_t;

后者还引入了别名gen_t对于类型struct impl_t。也可以看看C 标准的哪一部分允许编译此代码？ https://stackoverflow.com/questions/12200096/which-part-of-the-c-standard-allows-this-code-to-compile and C标准是否认为存在一两个struct uperms此标头中的条目类型？ https://stackoverflow.com/questions/11697705/does-the-c-standard-consider-that-there-are-one-or-two-struct-uperms-entry-typ

原本的main()问题中的程序是：

int main (int argc, char *argv[]) {
    int  ret;
    gen_t  data;

    ret = foo(&data);
    …
}

此代码无法编译gen_t作为不透明（非指针）类型。它可以与以下内容一起使用：

typedef struct impl_t *gen_t;

它不会编译：

typedef struct impl_t gen_t;

因为编译器必须知道结构有多大才能为其分配正确的空间data，但是编译器无法根据不透明类型的定义知道该大小。 （看这是一个好主意吗typedef指点？ https://stackoverflow.com/questions/750178/typedef-pointers-a-good-idea/750208#750208用于定义指向结构的指针。）

就这样main()代码应该更像是：

#include "generic.h"

int main(int argc, char **argv)
{
    gen_t *data = bar(argc, argv);
    int ret = foo(data);
    ...
}

其中（对于本例）bar()定义为extern gen_t *bar(int argc, char **argv);，所以它返回一个指向不透明类型的指针gen_t.

关于是否始终使用更好的观点存在分歧struct tagname或使用typedef为了名字。 Linux 内核是一个不使用typedef机制;所有结构都明确struct tagname。另一方面，C++ 不再需要显式的typedef;写作：

struct impl_t;

在 C++ 程序中意味着名称impl_t现在是一个类型的名称。由于不透明的结构类型需要标签（或者您最终会使用void *对于所有事情，这出于多种原因都是不好的，但主要原因是您失去了所有类型安全性void *;记住，typedef引入了基础类型的别名，而不是新的不同类型），我用 C 编写的代码模拟了 C++：

typedef struct Generic Generic;

I avoid using the _t suffix on my types because POSIX reserves the _t for the implementation to use^* (see also What does a type followed by _t represent? https://stackoverflow.com/questions/231760/what-does-a-type-followed-by-t-underscore-t-represent/231807#231807). You may be lucky and get away with it. I've worked on code bases where types like dec_t and loc_t were defined by the code base (which was not part of the implementation — where 'the implementation' means the C compiler and its supporting code, or the C library and its supporting code), and both those types caused pain for decades because some of the systems where the code was ported defined those types, as is the system's prerogative. One of the names I managed to get rid of; the other I didn't. 'Twas painful! If you must use _t (it is a convenient way to indicate that something is a type), I recommend using a distinctive prefix too: pqr_typename_t for some project pqr, for example.

^{* See the bottom line of the second table in The Name Space http://pubs.opengroup.org/onlinepubs/9699919799/functions/V2_chap02.html#tag_15_02_02 in the POSIX standard.}