我们都知道全局变量是可以避免的，但是将它们置于命名空间中是一个解决方案还是只是另一种形式的同一问题？拥有像任何人都可以在名称空间中访问和更改的数组这样的东西仍然很糟糕吗？ 有变量时有没有其他选择：
命名空间使得更容易理解是否需要更多像这样的变量，所有变量都与相同的想法相关。它们还可以更容易地跟踪。这些是唯一能让他们变得更好而不仅仅是拥有全球性的东西吗？我不是要淡化他们的重要性，只是好奇 考虑到这一点，在C＃全局静态类成员基本上与此相同。
编辑：毕竟为它制作了一个新类（并且像普通的那样通过ref传递它）。有可能它会成长，所以我觉得这个课很好。在写出命名空间之后，对于这种情况来说，这感觉就像是一个可怕的解决方案。
答案 0 :(得分：1)
全局变量存在（至少）三个独立的困难。它们：
1）防止其他人使用相同的名称（或者如果他们这样做，他们会影响你的名字，这可能会令人困惑）。将东西放在命名空间中有助于此。
2）难以同时推断直接修改全局的所有代码。除了匿名命名空间之外，命名空间对此没有帮助，因为它们可用于限制对全局到一个TU的访问。使用私有静态类成员，或许可以使用friend，可以提供帮助。非可变全局变量也有帮助。
3）难以同时推断间接修改全局的所有代码，因此难以推断全局的当前状态应该在程序中的任何指定点。不可变的全局变量有帮助。其状态不关心帮助的全局变量（例如，如果正确处理缓存过时，它可能不会影响代码的正确性，无论给定结果是否已经缓存）。命名空间没有帮助。在隐藏公共访问者的同时“隐藏”私人数据成员中的全球状态并没有帮助。
那么，命名空间是否有助于全局变量的困难？一点点，但不多。
如果您了解全局变量的其他困难，那么您可以自己评估命名空间是否有用。如果你没有意识到全局变量的困难，那么你就不会因为某种宗教信仰而避免使用它们而只是因为有人告诉你每个人都知道它们是坏事。有一种方法可以让人意识到有人愿意教你一些东西，而不仅仅是试图吓唬你成为一名优秀的程序员。另一种方法是使用它们，看看你遇到了什么麻烦，如果有的话。
答案 1 :(得分：0)
我认为这只是同一问题的一部分。为什么在考虑将变量放入命名空间之前不要问自己呢
问题）这个变量/数组是否可以在其生命周期内包含在类中，而任何其他需要它的类都包含对该变量的指针/引用。
通常允许类通过指针访问变量，你可以像处理全局变量那样对待它，只需确保将它传递给构造函数，或者为它设置一个setter
通常，您的类希望封装对象状态，并使用函数来操作它。另一方面，命名空间可以更多地被视为用于解决任务的相关函数的分组，即std命名空间，例如......
std::cout << "msg here" << std::endl;
在此示例中，此命名空间中包含的函数用于将缓冲区打印到屏幕并刷新输出
答案 2 :(得分：0)
当我们以OOP风格设计程序时，我们将其定义为实体的交互。实体在实现细节中隐藏它们的状态，并提供接口（以使交互成为可能）。证明将所有实体定义为类是有效的。如果我们有全局变量，那么我们就会妥协美和打破内置原则，让实体状态裸露在任何类之外。在这种情况下，命名空间无法帮助我们。