Typedef不会提供一组相互依赖的数据结构。你不能用typdef做到这一点:

struct bar;
struct foo;

struct foo {
    struct bar *b;
};

struct bar {
    struct foo *f;
};

当然你还可以加上:

typedef struct foo foo_t;
typedef struct bar bar_t;

这到底有什么意义?

Typedef不会提供一组相互依赖的数据结构。你不能用typdef做到这一点:

struct bar;
struct foo;

struct foo {
    struct bar *b;
};

struct bar {
    struct foo *f;
};

当然你还可以加上:

typedef struct foo foo_t;
typedef struct bar bar_t;

这到底有什么意义?

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

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

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来表示标准库类型名称。

一个有用的信息来源是《Expert C Programming》(第3章)。简单地说，在C语言中你有多个命名空间:标记、类型、成员名和标识符。Typedef为类型引入别名，并将其定位在标记命名空间中。也就是说,

typedef struct Tag{
...members...
}Type;

定义了两个东西。1)在标签命名空间中标记，2)在类型命名空间中键入。你可以同时使用myType和struct Tag myTagType。像struct Type myType或Tag myTagType这样的声明是非法的。此外，在这样的声明中:

typedef Type *Type_ptr;

定义一个指向类型的指针。如果我们声明:

Type_ptr var1, var2;
struct Tag *myTagType1, myTagType2;

那么var1,var2和myTagType1是指向Type的指针，而myTagType2不是。

在上面提到的书中，它提到对结构进行类型定义并不是很有用，因为它只是让程序员不用编写struct这个词。然而，像许多其他C程序员一样，我有一个反对意见。虽然有时会混淆一些名称(这就是为什么在像内核这样的大型代码库中不可取的原因)，但当您想在C中实现多态性时，查看这里的详细信息会有很大帮助。例子:

typedef struct MyWriter_t{
    MyPipe super;
    MyQueue relative;
    uint32_t flags;
...
}MyWriter;

你可以:

void my_writer_func(MyPipe *s)
{
    MyWriter *self = (MyWriter *) s;
    uint32_t myFlags = self->flags;
...
}

因此，您可以通过强制转换通过内部结构(mpipe)访问外部成员(flags)。对我来说，强制转换整个类型比执行(struct MyWriter_ *) s;每次你想执行这样的功能。在这种情况下，简要引用是很重要的，特别是当你在代码中大量使用这种技术时。

最后，与宏相比，类型定义类型的最后一个方面是无法扩展它们。例如，你有:

#define X char[10] or
typedef char Y[10]

然后你可以声明

unsigned X x; but not
unsigned Y y;

对于结构体，我们并不关心这一点，因为它不适用于存储说明符(volatile和const)。

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.

使用typedef可以避免每次声明该类型的变量时都要写struct:

struct elem
{
 int i;
 char k;
};
elem user; // compile error!
struct elem user; // this is correct