【问题标题】:Lesser of two evils when using globals via extern通过 extern 使用全局变量时,两害相权取其轻
【发布时间】:2013-07-09 01:36:11
【问题描述】:
我正在处理一些使用许多全局变量的旧代码。我完全了解使用全局变量的许多缺点,所以我的问题不在于我是否应该使用全局变量。
在查看了大部分代码后,我注意到了两种模式,我正在尝试确定哪一种更糟糕以及为什么。
这两种模式的相似之处在于全局变量使用“extern”公开。
两种模式的主要区别在于:
一些全局变量在头文件中被外部化/暴露,它们位于
使用#include 将其包含在许多源文件中
其他全局变量直接在源文件本身中外部/公开
您认为这两个中的哪一个比另一个更糟糕?为什么?
你会认为它们同样糟糕吗?为什么?
【问题讨论】:
标签:
c
design-patterns
global-variables
extern
【解决方案1】:
1) 尽可能隐藏。如果它们不需要可见,则不允许人们使用它们(通过提供他们的声明)。
2) 如果 extern 不是必需的,请使用 static 并且......隐藏你可以隐藏的东西。
您认为这两个中的哪一个比另一个更糟糕?为什么?
第一个;因为它对其他翻译不必要地可见。第二个可能导致链接器错误,但需要内部知识才能在另一个源/翻译中正确使用。然后可以通过将其设为static 来解决链接器问题(同样,如果它的声明对一个翻译可见)。
你会认为它们同样糟糕吗?为什么?
没有。如果您可以隐藏全局变量的实现并限制它们的访问,那么您已经帮了您的代码库一个忙。
【解决方案2】:
我倾向于认为 C 头文件属于以下三个类别之一:公共、私有和受保护(不要与 C++ 关键字或相同名称混淆)。 Public 适用于任何人都可以访问的任何内容。 Private 用于仅用于模块内部实现的所有内容(如果拆分为多个文件);这些在模块之外永远不可见。受保护的是那些通常不会被另一个模块访问但由于某种原因需要访问的项目(模块耦合可能在此处发生)。
对我来说,在 C 源文件而不是头文件中外显的符号(例如全局变量)违反了这些“规则”,并被解释为代码异味。
希望这会有所帮助。