在C ++中，可以在翻译单元中使用static关键字来影响符号的可见性（变量或函数声明）。
在n3092中，这已被弃用：
附件D.2 [depr.static]
在声明命名空间范围内的对象时，不推荐使用static关键字（参见3.3.6）。
在n3225中，这已被删除。
only article I could find有点不正式。
但它确实强调，为了与C兼容（以及将C程序编译为C ++的能力），弃用令人讨厌。但是，直接用C ++编译C程序可能会令人沮丧，所以我不确定它是否值得考虑。
有谁知道为什么会改变它？
答案 0 :(得分：68)
1012下的C++ Standard Core Language Defect Reports and Accepted Issues, Revision 94。他们注意到：
尽管7.3.1.1 [namespace.unnamed]声明不推荐使用static关键字来声明命名空间作用域中的变量，因为未命名的命名空间提供了一个更好的替代方案，因此不可能在任何时候删除该功能。可预见的未来。
基本上说static的弃用并不合理。它永远不会从C ++中删除，它仍然有用，因为如果你只想声明一个带有内部链接的函数或对象，你不需要你需要的未命名命名空间的样板代码。
答案 1 :(得分：27)
我会尝试回答你的问题，虽然这是一个老问题，但它看起来并不重要（它本身并不是很重要本身），并且它已经收到了很好的答案已经。我想回答的原因是，当语言基于现有语言时，它涉及标准进化和语言设计的基本问题：何时应该以不兼容的方式弃用，删除或更改语言功能？
在C ++中，可以在翻译单元中使用static关键字来影响符号的可见性（变量或函数声明）。
实际上是联系。
在n3092中，这已被弃用：
弃用表示：
后一点很重要。虽然从来没有一个正式承诺，你的程序不会被破坏，有时默默地，通过下一个标准，委员会应该尽量避免违反“合理”的代码。弃用应告诉程序员依赖某些功能是不合理的。
但它确实强调，为了与C兼容（以及将C程序编译为C ++的能力），弃用令人讨厌。但是，直接用C ++编译C程序可能会令人沮丧，所以我不确定它是否值得考虑。
保留C / C ++公共子集非常重要，特别是对于头文件。当然，static全局声明是带有内部链接的符号声明，这在头文件中不是很有用。
但问题不仅仅是与C的兼容性，它与现有C ++的兼容性：有大量现有的有效C ++程序使用static全局声明。这段代码不仅正式合法，而且听起来很合理，因为它使用了明确定义的语言功能。
仅仅因为现在有一种“更好的方式”（根据一些人的说法）做某事并不能使程序以旧方式“坏”或“不合理”。在C和C ++社区中，可以很好地理解在全局范围内对对象和函数声明使用static关键字的能力，并且通常使用正确。
同样地，我不会仅仅因为“C风格的演员阵容不好”而将C风格的演员表改为double改为static_cast<double>，因为static_cast<double>添加零信息零安全。
每当发明一种新的做事方式时，所有程序员都会急于重写现有明确定义的工作代码，这简直就是疯了。 如果你想删除所有继承的C ugliness和问题，你不要改变C ++，你发明了一种新的编程语言。半删除static的一次使用几乎不会使C ++减少C -ugly。
代码更改需要一个理由，“旧有坏”绝不是代码更改的理由。
突破语言变化需要非常强有力的理由。使语言变得非常简单，这绝不是破坏性变革的理由。
给出static为什么不好的原因只是非常微弱，甚至不清楚为什么不同时弃用对象和函数声明 - 给它们不同的处理几乎不会使C ++更简单或更正交。 / p>
所以，真的，这是一个悲伤的故事。不是因为它具有实际后果：它实际上没有实际后果。但是因为它显示出ISO委员会明显缺乏常识。
答案 2 :(得分：12)
是否弃用，删除此语言功能会破坏现有代码并使人烦恼。
整个静态弃用的东西只是一厢情愿的想法，“匿名命名空间优于静态”，“引用是更好的指针”。洛尔。