弃用静态关键字…不再？

在C ++中，可以在翻译单元中使用static关键字来影响符号的可见性（variables或函数声明）。

在3092年，这是不赞成的：

附件D.2 [depr.static]
在命名空间范围内声明对象时，不推荐使用static关键字（见3.3.6）。

在n3225，这已被删除。

我能find的唯一文章是有些不正式的。

但是为了与C兼容（以及用C ++编译C程序的能力），它的确强调了这一点。然而，直接编译一个C程序可能是一个令人沮丧的经验，所以我不确定是否值得考虑。

有谁知道它为什么被改变？

在C ++标准核心语言缺陷报告和被接受的问题，修订版94在1012下。取消静态静态 `他们注意到：

尽pipe7.3.1.1 [namespace.unnamed]指出，在命名空间范围内使用static关键字来声明variables已被废弃，因为未命名的命名空间提供了一个更好的select，在可预见的将来，这个function不太可能被删除。

基本上说， static的贬值并不合理。它永远不会被从C ++中移除，而且它仍然很有用，因为如果你只是想声明一个具有内部链接的函数或对象，那么你不需要使用未命名的名称空间所需的样板代码。

我会尽量回答你的问题，虽然这是一个老问题，看起来并不重要（本身并不重要），已经收到了相当好的答案。我想回答这个问题的原因是，当语言是基于现有语言的时候，它涉及标准进化和语言devise的基本问题： 语言特征何时应该以不兼容的方式被弃用，删除或改变？

在C ++中，可以在翻译单元中使用static关键字来影响符号的可见性（variables或函数声明）。

实际上的联系。

在3092年，这是不赞成的：

弃用表示：

意图在未来删除某些function; 这并不意味着弃用的function将在下一个标准修订版本中被删除，或者它们必须“很快”被删除，或者根本不需要删除。在下一个标准版本中可能会删除不推荐使用的function。
阻止其使用的正式尝试。

后一点很重要。虽然从来没有正式的承诺，你的程序不会被打破，有时候会默默地按照下一个标准，委员会应该尽量避免打破“合理”的代码。弃用应该告诉程序员， 依靠某些function是不合理的 。

但是为了与C兼容（以及用C ++编译C程序的能力），它的确强调了这一点。然而，直接编译一个C程序可能是一个令人沮丧的经验，所以我不确定是否值得考虑。

保留一个C / C ++公共子集非常重要，尤其是头文件。当然， static全局声明是带有内部链接的符号声明，这在头文件中不是很有用。

但问题不在于与C兼容，而是与现有C ++的兼容性：现有大量有效的C ++程序使用static全局声明。这个代码不仅在forms上合法，而且是合理的，因为它使用了一个明确定义的语言特征 ，并且它的使用方式也是如此 。

正因为现在有一个“更好的方法”（据某些人）做某事不会使程序以旧的方式写成“坏”或“不合理的”。在C和C ++社区都很好的理解在全局范围使用static关键字来声明对象和函数的能力，而且经常正确地使用。

同样，我不会因为“C风格的转换是坏的”而将C风格的转换double到static_cast<double> ，因为static_cast<double>增加了零信息和零安全性。

这样的想法是，每当发现一种新的方式去做某件事时，所有的程序员都会急于重写他们现有的定义明确的工作代码。 如果你想删除所有的inheritance性的问题，你不要改变C ++，你发明了一种新的编程语言。 使用static几乎不会使C ++变得更加丑陋。

代码更改需要一个理由，“老是坏”从来不是代码更改的理由。

打破语言的变化需要一个非常有力的理由。让语言变得简单一点也不是一个突破性改变的理由。

给出static为什么不好的原因很明显很弱，为什么不把两个对象和函数声明一起弃用 – 给予它们不同的处理几乎不使C ++更简单或更正交。

所以，真的，这是一个悲伤的故事。不是因为它的实际后果：它实际上没有什么实际后果。但是因为它显示了ISO委员会明显缺乏常识。

不赞成使用，删除这个语言function会破坏现有的代码并惹恼人们。

整个静态贬义的事情只是一厢情愿的想法，“匿名命名空间比静态更好”和“引用是更好的指针”。大声笑。