我看到结构以两种不同的方式宣告。
typedef struct _myStruct {
...
} myStruct;
和
typedef struct myStruct {
...
} myStruct;
是否有理由领先下划线或这只是一个风格的东西？如果没有差异，这些中的一个优先于另一个吗？
答案 0 :(得分：5)
前者很久以前就被使用了，当时一些编译器不允许标签和typedef使用相同的标识符。后者目前是首选，事实上，不鼓励以下划线开头的标识符。
答案 1 :(得分：2)
有理由不使用前导下划线，特别是以下划线开头的名称基本上保留供实现使用。细节比这更细微，但更容易记住。
ISO / IEC 9899：2011
7.1.3保留标识符
7.1.3保留标识符
¶1每个标头声明或定义其相关子条款中列出的所有标识符，并可选地声明或定义其关联的未来库方向子条款和标识符中列出的标识符，这些标识符始终保留用于任何用途或用作文件范围标识符。
- 所有以下划线开头且以大写字母或其他下划线开头的标识符始终保留供任何使用。
- 所有以下划线开头的标识符始终保留用作普通和标记名称空间中具有文件范围的标识符。
- ...
因此，使用领先的下划线是在薄冰上踩踏。通常，你会逃脱。但是，有时你不会，当你不会，你没有追索权，因为你已经超出了标准允许你使用的命名空间的限制。
如果结构标记和类型名称相同，则不必猜测哪个结构标记与哪个类型名称（别名）有关。
请注意，Linux内核编码标准拒绝结构的typedef。您必须决定是否要遵循该规则。许多系统都没有遵循它。
另一个小问题是C ++在使用标记名称定义typedef struct MyStruct MyStruct;或class（或struct）后自动执行相当于union的操作，您可以使用标记名称作为类型名称。它不完全相同 - 你可以自己做typedef并且它可以干净地编译。
答案 2 :(得分：0)
完全风格。只是在视觉上区分＆＃34;合成类型＆＃34;来自该类型的声明变量。
答案 3 :(得分：0)
我倾向于： -
typedef struct {
...
} myStruct;