声明全局变量是否有任何不利条件? [英] Is there any disadvantage to declare a variable global?

问题描述

在C ++语言中，声明全局变量是否有缺点?

In C++ language is there any disadvantage to declare a variable global?

void foo()
{
  int a;
  a=10;
}

int a;
void foo()
{
  a=10;
}

它们之间有什么区别吗?

Any differences between them?

推荐答案

为什么在不必要时应避免使用全局变量

• 非本地性-当单个元素的范围受到限制时，最容易理解源代码.可以读取全局变量或由程序的任何部分修改，使其很难记住或解释每种可能的用法.
• 无访问控制或约束检查-程序的任何部分以及有关其使用的任何规则都可以获取或设置全局变量容易被打破或遗忘.(换句话说，获取/设置访问器通常比直接数据访问更可取，甚至对于全局数据更是如此.)通过扩展，缺少访问控制在您可能希望的情况下极大地阻碍了安全性运行不受信任的代码(例如使用第三方插件).
• 隐式耦合-具有很多全局变量的程序通常在其中一些变量之间具有紧密的耦合，而在这些变量之间却存在紧密的耦合变量和函数.将耦合项分组为内聚单元通常可以带来更好的程序.
• 并发问题-如果可以通过多个执行线程访问全局变量，则同步是必要的(而且经常被忽略).将模块与全局变量动态链接时，组成的系统即使两个独立的模块在数十种不同的情况都是安全的.
• 命名空间污染-全球名称随处可见.当您认为自己使用的是本地(通过拼写错误或忘记声明本地)反之亦然.另外，如果您必须将具有以下功能的模块链接在一起相同的全局变量名称，如果幸运的话，您将获得链接错误.如果您不走运，则链接器将仅处理的所有使用与同一对象的名称相同.
• 内存分配问题-某些环境具有内存分配方案，使全局分配变得棘手.特别是在构造函数"具有除以下之外的副作用的语言中为真分配(因为在这种情况下，您可以表达不安全的情况两个全局变量相互依赖的地方).还有，什么时候动态链接模块，可能不清楚是否不同图书馆有自己的全局实例，或者是否具有全局实例共享.
• 测试和禁闭-利用全局变量的源很难测试，因为无法轻易建立干净"的环境运行之间的环境.更普遍的是，利用全球各种服务(例如，读取和写入文件或数据库)没有明确提供给该来源的内容很难测试为了同样的原因.对于通信系统，具有测试能力系统不变量可能需要运行一个系统的多个副本"同时使用，任何共享方式的使用都会大大阻碍不提供共享的服务-包括全局内存作为测试的一部分.

• Non-locality -- Source code is easiest to understand when the scope of its individual elements are limited. Global variables can be read or modified by any part of the program, making it difficult to remember or reason about every possible use.
• No Access Control or Constraint Checking -- A global variable can be get or set by any part of the program, and any rules regarding its use can be easily broken or forgotten. (In other words, get/set accessors are generally preferable over direct data access, and this is even more so for global data.) By extension, the lack of access control greatly hinders achieving security in situations where you may wish to run untrusted code (such as working with 3rd party plugins).
• Implicit coupling -- A program with many global variables often has tight couplings between some of those variables, and couplings between variables and functions. Grouping coupled items into cohesive units usually leads to better programs.
• Concurrency issues -- if globals can be accessed by multiple threads of execution, synchronization is necessary (and too-often neglected). When dynamically linking modules with globals, the composed system might not be thread-safe even if the two independent modules tested in dozens of different contexts were safe.
• Namespace pollution -- Global names are available everywhere. You may unknowingly end up using a global when you think you are using a local (by misspelling or forgetting to declare the local) or vice versa. Also, if you ever have to link together modules that have the same global variable names, if you are lucky, you will get linking errors. If you are unlucky, the linker will simply treat all uses of the same name as the same object.
• Memory allocation issues -- Some environments have memory allocation schemes that make allocation of globals tricky. This is especially true in languages where "constructors" have side-effects other than allocation (because, in that case, you can express unsafe situations where two globals mutually depend on one another). Also, when dynamically linking modules, it can be unclear whether different libraries have their own instances of globals or whether the globals are shared.
• Testing and Confinement - source that utilizes globals is somewhat more difficult to test because one cannot readily set up a 'clean' environment between runs. More generally, source that utilizes global services of any sort (e.g. reading and writing files or databases) that aren't explicitly provided to that source is difficult to test for the same reason. For communicating systems, the ability to test system invariants may require running more than one 'copy' of a system simultaneously, which is greatly hindered by any use of shared services - including global memory - that are not provided for sharing as part of the test.

这篇关于声明全局变量是否有任何不利条件?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！