是否存在" struct命名空间的技术原因"在C?

时间:2014-11-30 11:34:35

标签: c namespaces

在C中,大多数声明结构的代码都将遵循以下模式:

/* struct forward-declaration */
typedef struct T T ;

/* struct definition */
typedef struct T
{
   /* etc. */
} T ;

这是如此普遍,我与之交谈的大多数开发人员甚至都不知道上面的代码同时做了两件事(结构声明,然后在正常的命名空间中对结构名称进行别名),并且只是习惯性地写出来了。

在C ++中,问题得到缓解,因此您可以省略typedefing部分。在C#和Java中,设计师甚至都没有打扰。所以这些语言无法理解为什么C会这样做。

所以,在Oliver Charlesworth的建议之后:

是否有技术原因让struct T与其他普通标识符位于不同的名称空间中?

修改

C89 / C90标准中的相关部分是:

  

6.1.2.3标识符的名称空间

     

在翻译单元的任何一点都可以看到多个特定标识符的声明。句法上下文消除了引用不同实体的用法。从而。对于各种类别的标识符,都有单独的名称空间,如下所示:

     
      
  • [...]

  •   
  • 结构,联合和枚举的标记(通过遵循任何关键字 struct union 枚举)。

  •   
  • [...]

  •   
  • 所有其他标识符。称为普通标识符(在普通声明符中声明或作为枚举常量声明)。

  •   

C11(n1570:6.2.3标准草案)的文本或多或少相同。

1 个答案:

答案 0 :(得分:0)

只有在第二个声明中使用名称struct T引用T时才需要第一行。

对于不包含此类引用的结构,只需要第二种形式。对于这种情况,为了简单和简洁,我建议删除那个毫无意义的struct标签:

typedef struct {
  /* interesting fields go here */
} T;

此外,typedef不会“将结构名称带入正常的名称空间”,它会创建(如typedef总是这样)别名({{1 }})用于不同的类型名称T。当然,这里的名称拼写之间没有联系,这就是为什么我建议首先删除标记struct T,它只是添加了一个大多数时候没有意义的名称。