为什么要对结构使用typedef？

在C语言（ANSI，C99等）中，结构存在于自己的名称空间中。链表的结构可能看起来像这样：

struct my_buffer_type {
   struct my_buffer_type * next;
   struct my_buffer_type * prev;
   void * data;
};

然而，对于大多数C程序员来说，自动对这些结构进行如下类型的定义似乎是很自然的：

typedef struct tag_buffer_type {
   struct tag_buffer_type * next;
   struct tag_buffer_type * prev;
   void * data;
} my_buffer_type;

然后像普通类型一样引用该结构，即get_next_element(my_buffer_type * ptr)。

现在我的问题是：是否有特定原因？

维基百科说http://en.wikipedia.org/wiki/Typedef#Usage_concerns

有些人反对typedef的广泛使用。大多数参数都以typedef仅隐藏变量的实际数据类型为中心。例如，Linux内核黑客和文档编制者Greg Kroah-Hartman阻止将它们用于除函数原型声明以外的任何内容。他认为这种做法不仅不必要地混淆了代码，而且还可能导致程序员意外地滥用大型结构，认为它们是简单的类型。[4]

其他人则认为，使用typedef可以使代码更易于维护。K＆R指出使用typedef有两个原因。首先，它提供了使程序更具可移植性的方法。不必更改在程序源文件中出现的所有类型的类型，只需更改单个typedef语句即可。其次，typedef可以使复杂的声明更易于理解。

我个人想知道，使用单独的struct命名空间是否有时没有使用类型定义的结构没有足够的好处，并且由于周围存在着几种C编程文化（我的经验是Windows C编程与Linux C编程有着不同的传统），如果还有其他我不了解的传统。

然后，我对历史考量（C的前身，第一个版本）感兴趣。

我从事了一个大型项目，该项目广泛使用typedef的结构。我们这样做有两个原因。请记住，这是C99之前的版本和名称空间分离。

1. 键入起来更容易，my_buffer_type *buffer而不是struct tag_buffer_type *buffer，而且代码库的大小（1M + loc）也有很大的不同。

2. 它将结构抽象为一个对象。与其关注结构中的每个变量，不如关注其表示的数据对象。这种抽象通常导致更有用和更容易编写代码。

   • 我认为这与您提供给格雷格·克劳·哈特曼（Greg Kroah-Hartman）的报价直接矛盾。FWIW，该项目是一个客户端/服务器应用程序，而不是内核，因此肯定有一些不同的考虑因素。

3. 将结构视为对象也使我们能够更好地封装信息。代码审查发现了很多情况，新开发者会违反我们已经采用的封装原则。使用typedef的结构确实使那些违规变得显而易见。

4. 在我们为服务器的六个平台和客户端的许多平台编写的文章中，可移植性是一个令人担忧的问题。

每次不用打字

struct my_buffer_type *buffer;

如果您typedef可以直接使用

my_buffer_type *buffer;

typedef的主要用途是减少编写代码所需的击键次数并增强可读性。