在typedef and struct namespaces in C vs C++ 中，其中一个 cmets 似乎暗示暴露一些 struct foo 比使用 typedef 更可取...
typedef struct foo foo;
...然后在整个 API 中使用 foo 而不是 struct foo。
后一种变体有什么缺点吗？
【问题讨论】：
foo 而不是 struct foo 而无需任何明确的 typedef）。
标签： c coding-style
唯一的缺点 (*) 是它隐藏了 foo 是一个结构，而不是某些内置类型的别名这一事实。
注意(*)：这对你来说是否不利是个人喜好问题。
【讨论】：
这取决于您对struct 这个词的喜爱程度。如果你觉得你的程序会被struct that 和struct tother （当然你不能在C++ 中使用struct this）使你的程序更清晰，那么一定要使用struct 版本。
就我个人而言，我不认为重复 struct 会带来任何好处，我很乐意只使用 typedef 名称。而且因为 C++ 有效地自动提供了 typedef struct xyz xyz; 声明（它不是很准确，尤其是因为你可以用 C++ 显式编写它，但它足够接近，你可能不必担心它），我认为在 C 中使用它是非常有意义的。C 编译器对此很满意，所以我通常使用 typedef struct tag tag;，然后在需要时使用 tag 和 tag *。
对于另一种但完全站得住脚的观点，请阅读Linux kernel coding style 指南。
请注意，C2011 允许您重新定义 typedef，只要它别名相同的类型：
ISO/IEC 9899:2011 §6.7 声明
语义
¶5 声明指定一组标识符的解释和属性。定义 标识符的声明是该标识符的声明：
——对于一个对象，导致为该对象保留存储空间；
——对于函数，包括函数体；119)
——对于枚举常量，是标识符的（唯一）声明；
——对于 typedef 名称，是标识符的第一个（或唯一一个）声明。
与 C99 对比，这是不可能的：
语义
¶5 声明指定一组标识符的解释和属性。定义 标识符的声明是该标识符的声明：
——对于一个对象，导致为该对象保留存储空间；
——对于函数，包括函数体；98)
——对于枚举常量或 typedef 名称，是（唯一的）声明 标识符。
只要您保持一致，这就会简化类型定义的创建（但前提是您在与您相关的每个平台上都有足够兼容的 C2011 编译器）。
【讨论】：
关于是否typedef结构类型：
这里有一些意见（都反对类型定义结构）：
来自 OpenBSD 风格指南：
“避免对结构类型使用 typedef。这使得应用程序无法不透明地使用指向此类结构的指针，这在使用普通结构标记时既可行又有益。”
来自 Linux 内核编码风格：
“将 typedef 用于结构和指针是一个错误。”
来自 Peter Van der Linden 的 Expert C Programming：
“不要为结构体的 typedefs 操心。它们所做的只是省去你写“结构体”这个词的麻烦，这是一个你可能不应该隐藏的线索。”
【讨论】：
typedef struct foo foo; 可用于不透明指针，并且也是有效的 C++；虽然如果你不使用 typedef，你可以在没有显式前向声明 struct foo; 的情况下声明指针变量，但无论如何你都应该添加一个：否则，如果结构的第一次出现是在函数声明中，则类型将具有原型范围，这很少需要 - 虽然由于类型兼容性规则它实际上并没有害处，但编译器可能会警告它......
void foo(struct bar *);void foo(struct bar *); 将无法编译，因为这两种struct bar 类型将不兼容...
这或多或少是一个品味问题。
只需声明一个struct 标记，该名称也可用于同一范围内的变量、函数或枚举器（如果您喜欢混淆，甚至可以是其他类型）；并且用户必须写struct这个词，这使得他们的代码更加明确。
通过同时声明类型名称，您可以允许人们在不想输入时不要输入struct。
我在另一个问题中的评论是指与结构标签同名的 pointer 类型的声明：
typedef struct foo * foo;
在风格上，这有点令人不快，因为它隐藏了它是一个指针的事实。这隐藏了它是一个指针的事实；在那个问题的上下文中，这可能很好，这是由 API 定义的不透明类型，但在我看来，对于非透明类型来说是相当粗鲁的。它还破坏了与 C++ 的兼容性。在该语言中，这样的声明是无效的，因为struct foo 将foo 引入当前命名空间而不是单独的标记空间，并阻止在该命名空间中声明具有相同名称的任何其他类型。
【讨论】：
typedef struct foo foo; 一样执行它们，然后强制调用者使用指针表示法将它们的对象声明为 foo* obj;。这与在调用者使用动态分配时强制调用者使用指针本质上是一样的。你永远不会看到像typedef void* malloc_t; ... malloc_t obj = malloc(...); 这样的东西，那么为什么不透明类型会有所不同。
malloc 的调用者最终将不可避免地使用其返回值作为指针，而并非所有函数都如此。如果你的 API 返回的东西就调用者而言纯粹是一个不透明的句柄，但出于实现原因，它实际上是一个地址很方便，那么 IMO 你不应该仅仅因为你觉得句柄类型是指针类型指针是通常的经验法则的一个例外，即不相关的实现细节应该被隐藏。
malloc 的返回值不是不透明的；它是指向您请求的内存的指针）。
FILE* 是指针类型，而文件描述符是整数，这遵循您的规则，Lundin。但是对于用户来说，fopen 返回的类型是被称为FILE* 还是只是FILE 完全没有区别。如果我想实现文件系统 API，使得 FILE* 的值实际上只是转换为 FILE* 的 fd（或其他特定于操作系统的句柄），其中 FILE 是一个空结构，那么我几乎可以.调用者错误地认为它是一个地址这一事实只是一个小障碍，但我不会那样设计 API。
只要遵守命名约定就可以了。
typedef struct
{
//...
} t_mytype;
//...
t_mytype thing;
这样你就会知道它是一个自定义类型。至于它是一个结构，只需使用明确的名称而不是真正的t_mytype
【讨论】：
typedef struct { .. } mytype
反对 typedef 的另一个论点是它难以编写干净的标头。让我们看一个header的例子：
#ifndef HEADER_H
#define HEADER_H
#include "s.h"
void f(struct s *);
#endif
这个标题可以改进。事实上，struct s 不需要定义。所以可以写成：
#ifndef HEADER_H
#define HEADER_H
struct s;
void f(struct s *);
#endif
因此，用户可以将struct s 用作不透明结构，我们可以将"s.h" 保密。
让我们做同样的事情，但使用typedef：
#ifndef HEADER_H
#define HEADER_H
typedef struct s s_t;
void f(s_t *);
#endif
typedef struct s s_t 行将出现在每个想要使用s_t * 的标题中，我不喜欢冗余代码。有多种方法可以避免这种情况，但最简单的可能是摆脱 typedef。
【讨论】：