您(可选地)给结构的名称称为标记名称，正如前面所指出的，它本身并不是一个类型。要获得该类型，需要使用结构体前缀。

除了GTK+，我不确定tagname是否像struct类型的typedef一样常用，所以在c++中，这是可以识别的，你可以省略struct关键字，并使用tagname作为类型名:

struct MyStruct
{
  int i;
};

// The following is legal in C++:
MyStruct obj;
obj.i = 7;

正如Greg Hewgill所说，类型定义意味着你不再需要到处写struct。这不仅节省了击键，还可以使代码更简洁，因为它提供了更多的抽象。

之类的

typedef struct {
  int x, y;
} Point;

Point point_new(int x, int y)
{
  Point a;
  a.x = x;
  a.y = y;
  return a;
}

当你不需要到处看到“struct”关键字时，它看起来更像是在你的语言中真的有一个名为“Point”的类型。在typedef之后，我猜就是这个情况。

还要注意，虽然您的示例(和我的示例)省略了对结构体本身的命名，但当您希望提供不透明类型时，实际上对它进行命名也是有用的。然后你会在头文件中有这样的代码，例如:

typedef struct Point Point;

Point * point_new(int x, int y);

然后在实现文件中提供结构定义:

struct Point
{
  int x, y;
};

Point * point_new(int x, int y)
{
  Point *p;
  if((p = malloc(sizeof *p)) != NULL)
  {
    p->x = x;
    p->y = y;
  }
  return p;
}

在后一种情况下，您不能按值返回Point，因为它的定义对头文件的用户隐藏了。例如，这是GTK+中广泛使用的一种技术。

注意，在一些高度重视的C项目中，使用typedef来隐藏struct被认为是一个坏主意，Linux内核可能是最著名的这样的项目。关于Linus的愤怒言论，请参阅Linux内核编码风格文档的第5章。:)我的观点是，这个问题中的“应该”也许并不是一成不变的。

我认为typedef甚至不可能实现前向声明。使用struct, enum和union允许在依赖关系(知道)是双向的情况下转发声明。

风格: 在c++中使用typedef是很有意义的。在处理需要多个和/或变量参数的模板时，它几乎是必要的。typedef有助于保持命名的直直性。

在C编程语言中并非如此。typedef的使用通常没有任何目的，只会混淆数据结构的使用。由于只有{struct (6)， enum (4)， union(5)}个按键被用于声明一个数据类型，因此结构的别名几乎没有任何用处。数据类型是联合还是结构?使用简单的非类型定义声明可以让您立即知道它是什么类型。

请注意Linux是如何在编写时严格避免typedef带来的这种无意义的别名的。结果是一个极简主义和干净的风格。

在C语言中，struct/union/enum是由C语言预处理器处理的宏指令(不要与处理“#include”和other的预处理器混淆)

so :

struct a
{
   int i;
};

struct b
{
   struct a;
   int i;
   int j;
};

结构b是这样展开的:

struct b
{
    struct a
    {
        int i;
    };
    int i;
    int j;
}

因此，在编译时，它在堆栈上的演变是这样的: b: int人工智能 int我 int j

这也是为什么在不能终止的déclaration循环中很难有自不同的结构，C预处理器循环。

typedef是类型说明符，这意味着只有C编译器处理它，它可以像他想要的那样优化汇编代码实现。它也不会像préprocessor那样愚蠢地使用par类型的成员，而是使用更复杂的引用构造算法，因此构造如下:

typedef struct a A; //anticipated declaration for member declaration

typedef struct a //Implemented declaration
{
    A* b; // member declaration
}A;

是允许的，功能齐全。当执行线程离开初始化函数的应用程序字段时，这个实现还允许访问编译器类型转换，并删除一些bug影响。

这意味着在C中，typedef比单独的结构体更接近c++类。

一个> typdef允许为数据类型创建更有意义的同义词，从而帮助定义程序的含义和文档化。此外，它们还有助于参数化程序以解决可移植性问题(K&R, pg147, C prog lang)。

B > 结构定义了一种类型。Structs允许方便地将变量集合分组，以便将(K&R, pg127, C prog lang.)作为单个单元处理

C > 结构的类型定义在上面的a中有解释。

对我来说，struct是自定义类型、容器、集合、命名空间或复杂类型，而typdef只是一种创建更多昵称的方法。

Linux内核编码风格第5章给出了使用typedef的优点和缺点(主要是缺点)。

Please don't use things like "vps_t". It's a mistake to use typedef for structures and pointers. When you see a vps_t a; in the source, what does it mean? In contrast, if it says struct virtual_container *a; you can actually tell what "a" is. Lots of people think that typedefs "help readability". Not so. They are useful only for: (a) totally opaque objects (where the typedef is actively used to hide what the object is). Example: "pte_t" etc. opaque objects that you can only access using the proper accessor functions. NOTE! Opaqueness and "accessor functions" are not good in themselves. The reason we have them for things like pte_t etc. is that there really is absolutely zero portably accessible information there. (b) Clear integer types, where the abstraction helps avoid confusion whether it is "int" or "long". u8/u16/u32 are perfectly fine typedefs, although they fit into category (d) better than here. NOTE! Again - there needs to be a reason for this. If something is "unsigned long", then there's no reason to do typedef unsigned long myflags_t; but if there is a clear reason for why it under certain circumstances might be an "unsigned int" and under other configurations might be "unsigned long", then by all means go ahead and use a typedef. (c) when you use sparse to literally create a new type for type-checking. (d) New types which are identical to standard C99 types, in certain exceptional circumstances. Although it would only take a short amount of time for the eyes and brain to become accustomed to the standard types like 'uint32_t', some people object to their use anyway. Therefore, the Linux-specific 'u8/u16/u32/u64' types and their signed equivalents which are identical to standard types are permitted -- although they are not mandatory in new code of your own. When editing existing code which already uses one or the other set of types, you should conform to the existing choices in that code. (e) Types safe for use in userspace. In certain structures which are visible to userspace, we cannot require C99 types and cannot use the 'u32' form above. Thus, we use __u32 and similar types in all structures which are shared with userspace. Maybe there are other cases too, but the rule should basically be to NEVER EVER use a typedef unless you can clearly match one of those rules. In general, a pointer, or a struct that has elements that can reasonably be directly accessed should never be a typedef.