【问题标题】:How should I avoid naming collisions with included libraries in C?我应该如何避免与 C 中包含的库发生命名冲突?
【发布时间】:2019-10-04 21:39:52
【问题描述】:

我在项目的一个头文件中定义了一个枚举 TokenType

当我后来将<windows.h> 包含到某个标头中时,编译器抱怨它已经定义了自己的TokenType

C 中避免这种命名冲突的约定是什么?我必须用MyProject_ 前缀命名整个项目中使用的任何公共事物(函数、枚举、typedef 结构等)吗?例如MyProject_TokenType?看起来很丑。常见的方法是什么?

库的常用方法是什么,独立应用程序(例如我自己的)的方法是什么?

【问题讨论】:

  • 只是myTokenType?或更改名称以反映其用途/功能。
  • 在 C 中没有命名空间,因此在专业项目中通常会在所有全局标识符中添加项目前缀或(在大型项目中)模块前缀。
  • 可能会出现一些问题,例如创建一个包含库头文件的单独源文件并使用您自己的名称重新导出它们,但这些可能不够(例如,您的其他来源可能需要键入不容易用您自己的名字复制的定义)。这里的基本问题是第三方库可能设计不佳,并且可能没有很好的解决方案。写一个涵盖众多可能性的通用答案可能过于宽泛。解决具体问题可能是更合理的目标。
  • IMO 如果您的项目不是库,则不需要使用前缀——只需重命名您的东西,以防在添加库时出现冲突。 (当然,重命名的可行性取决于项目的规模和合作者的数量。)如果您的项目一个库(或具有类似库的部分),那么您将希望避免冲突与其他库一起使用,使用前缀是最常用的方法。还要尽量减少全局变量的数量(例如,尽可能使用文件static 范围)。
  • I big projects public (extern) 函数、类型和变量的前缀是文件名。 extern void myLib_nameOfMyFunction(void);。不适用于私有 (static) 函数、变量、类型。

标签: c namespaces naming-conventions


【解决方案1】:

由于 ANSI C 不支持命名空间,将项目/文件名添加到全局变量/类型是我迄今为止遇到的最实用的选项。虽然它使名称更长,但我也发现它更有条理和可读性,此外还有避免碰撞的优点。

【讨论】:

    猜你喜欢
    • 1970-01-01
    • 2021-04-15
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2013-11-13
    • 1970-01-01
    相关资源
    最近更新 更多