不赞成使用static关键字…不再吗？

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

在n3092中，已弃用：

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

在n3225中，已将其删除。

在我能找到的唯一的文章是有点非正式的。

它确实强调了，为了与C兼容（以及将C程序编译为C ++的能力），弃用是令人讨厌的。但是，直接将C程序编译为C ++可能会令人沮丧，因此我不确定是否值得考虑。

有谁知道为什么要更改？

在C ++标准核心语言缺陷报告和已接受的问题中，修订版94在1012下。不赞成使用静态`他们指出：

尽管7.3.1.1 [namespace.unnamed]声明不推荐使用static关键字在命名空间范围内声明变量，因为未命名的命名空间提供了更好的选择，但在可预见的将来不太可能删除该功能。 。

基本上说，弃用static并没有任何意义。它永远不会从C ++中删除，它仍然很有用，因为如果您只想声明具有内部链接的函数或对象，则不需要使用未命名空间的样板代码。

我将尝试回答您的问题，尽管这是一个古老的问题，并且看起来并不十分重要（它本身并不是很重要），并且已经收到了很好的答案。我要回答的原因是，当语言基于现有语言时，它与标准演变和语言设计的基本问题有关：应何时以不兼容的方式弃用，删除或更改语言功能？

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

实际的联系。

在n3092中，已弃用：

弃用表示：

• 的意图，以消除在未来的某个功能; 这并不意味着不赞成使用的功能将在下一个标准修订版中删除，或者必须“很快”删除或完全删除。并且在下一个标准修订版中可能会删除不推荐使用的功能。
• 阻止它使用的正式尝试。

后一点很重要。尽管从来没有正式的承诺说您的程序不会被下一个标准破坏，有时会无声地被打破，但是委员会应该设法避免破坏“合理的”代码。弃用应该告诉程序员，依赖某些功能是不合理的。

它确实强调了，为了与C兼容（以及将C程序编译为C ++的能力），弃用是令人讨厌的。但是，直接将C程序编译为C ++可能会令人沮丧，因此我不确定是否值得考虑。

保留C / C ++通用子集非常重要，尤其是对于头文件而言。当然，static全局声明是具有内部链接的符号声明，这在头文件中不是很有用。

但是问题不仅仅在于与C的兼容性，还在于与现有C ++的兼容性：存在大量使用static全局声明的现有有效C ++程序。这段代码不仅形式上合法，而且听起来很合理，因为它按照预期的方式使用了定义良好的语言功能。

仅仅因为现在有“更好的方法”（根据某些方法）来做某事，并不会使程序以旧的方式编写为“坏”或“不合理”。static在C和C ++社区中，对在全局范围内的对象和函数的声明中使用关键字的能力已广为人知，并且最常被正确使用。

同样，我不会因为“ C样式转换不好”而将C样式转换更改double为static_cast<double>，因为static_cast<double>添加了零信息和零安全性。

只要发明了一种新的做事方式，所有程序员都急于重写其现有的定义良好的工作代码这一想法真是太疯狂了。如果要消除所有继承的C丑陋和问题，而无需更改C ++，则可以发明一种新的编程语言。减少一半使用static几乎不会减少C ++的丑陋程度。

代码更改需要理由，而“老是坏”绝不是代码更改的理由。

打破语言变化需要非常有力的理由。使语言稍微简单一点绝不是进行重大更改的理由。

给出为什么static不好的原因非常明显，甚至不清楚为什么不同时弃用对象和函数声明-给它们不同的处理几乎不会使C ++更简单或更正交。

所以，真的，这是一个悲伤的故事。不是因为它带来的实际后果：它的实际后果是零。但这是因为它明显缺乏ISO委员会的常识。

不论是否赞成，删除此语言功能都会破坏现有的代码并惹恼人们。

整个静态弃用只是沿着“匿名名称空间比静态更好”和“引用是更好的指针”的思路。大声笑。