另一个总是对枚举和结构进行类型定义的原因是:

enum EnumDef
{
  FIRST_ITEM,
  SECOND_ITEM
};

struct StructDef
{
  enum EnuumDef MyEnum;
  unsigned int MyVar;
} MyStruct;

注意到结构(EnumDef)中的EnumDef中的错别字吗?这个编译没有错误(或警告)，并且(取决于C标准的字面解释)是正确的。问题是我刚刚在我的结构中创建了一个新的(空的)枚举定义。我没有(如预期)使用前面的定义EnumDef。

对于typdef，类似类型的打字错误将导致使用未知类型的编译器错误:

typedef 
{
  FIRST_ITEM,
  SECOND_ITEM
} EnumDef;

typedef struct
{
  EnuumDef MyEnum; /* compiler error (unknown type) */
  unsigned int MyVar;
} StructDef;
StrructDef MyStruct; /* compiler error (unknown type) */

我主张ALWAYS类型定义结构和枚举。

不仅是为了节省一些输入(没有双关语;))，而且因为它更安全。

让我们从最基本的开始，慢慢来。

下面是一个结构定义的例子:

struct point
  {
    int x, y;
  };

这里的名称点是可选的。

结构可以在定义期间声明，也可以在定义之后声明。

在定义期间声明

struct point
  {
    int x, y;
  } first_point, second_point;

在定义之后声明

struct point
  {
    int x, y;
  };
struct point first_point, second_point;

现在，仔细注意上面的最后一种情况;如果您决定稍后在代码中创建该类型，则需要编写struct point来声明该类型的结构。

输入类型。如果您打算在稍后使用相同的蓝图在程序中创建新的Structure (Structure是自定义数据类型)，那么在定义过程中使用typedef可能是一个好主意，因为您可以节省一些输入。

typedef struct point
  {
    int x, y;
  } Points;

Points first_point, second_point;

在命名自定义类型时要注意一点

没有什么可以阻止您在自定义类型名称的末尾使用_t后缀，但POSIX标准保留使用后缀_t来表示标准库类型名称。

在'C'编程语言中，关键字'typedef'用于为某些对象(struct, array, function..enum类型)声明一个新名称。例如，我将使用struct-s。 在C语言中，我们经常在main函数之外声明一个struct。例如:

struct complex{ int real_part, img_part }COMPLEX;

main(){

 struct KOMPLEKS number; // number type is now a struct type
 number.real_part = 3;
 number.img_part = -1;
 printf("Number: %d.%d i \n",number.real_part, number.img_part);

}

每次我决定使用结构体类型时，我将需要这个关键字'struct 'something' name'。'typedef'将简单地重命名该类型，我可以在我的程序中随时使用这个新名称。所以我们的代码是:

typedef struct complex{int real_part, img_part; }COMPLEX;
//now COMPLEX is the new name for this structure and if I want to use it without
// a keyword like in the first example 'struct complex number'.

main(){

COMPLEX number; // number is now the same type as in the first example
number.real_part = 1;
number.img)part = 5;
printf("%d %d \n", number.real_part, number.img_part);

}

如果你有一些局部对象(结构，数组，有价值的)，将在你的整个程序中使用，你可以简单地给它一个名字使用'typedef'。

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.

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

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

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

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

在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++类。