Question

我一直在阅读有关未命名命名空间的文章，大多数文章都解释了何时应该使用未命名的命名空间而不是static关键字。但是，当使用静态时，我还有一个大问题吗？毕竟它还没有被完全弃用，那么我应该将带有静态函数的头文件放入未命名的命名空间呢？

#ifndef HEADER_H
#define HEADER_H

static int func() {
  ...
}

// versus:

namespace {
  int func() {
    ...
  }
};

#endif // HEADER_H

或者静态成员函数怎么样？

问候

Answer 1

标准的准确措辞是：

在声明命名空间范围内的对象时，不推荐使用static关键字。

头文件中的函数应为inline而不是static或未命名的命名空间。 inline表示您最多只能获得程序中该函数的一个副本，而其他方法将为每个包含标题的文件提供单独的副本。除了膨胀之外，如果函数包含函数静态数据，这可能会给出不正确的行为。（编辑：除非该函数在不同的编译单元中具有不同的定义，可能是由于在包含头文件之前定义的不同预处理器宏。在这种情况下，最好的方法是不包括它根本就是把它埋在一个没有标记的坟墓中，并通过它不圣洁的心脏将其埋葬。）

除了常量之外，数据对象通常不应在头文件中定义，只能声明为extern。

静态成员函数是一个不同的鱼群，你必须在那里使用static，因为没有其他方法来声明它们。该用法不会被弃用，因为它不在命名空间范围内。

更新： C ++ 11已删除了弃用版，因此不再有任何特别的理由希望在static之外使用未命名的命名空间。但你仍然不应该在头文件中使用它们，除非你做了一些奇怪的事情。

Answer 2

我知道，命名空间范围中的静态优于未命名的命名空间。使用未命名的命名空间，如上例所示。实际上在上面的例子中，我看不出为什么需要静态或未命名的命名空间。也许是内联？静态成员函数与命名空间范围内的静态无关。静态成员函数（和非函数成员）仍然有效。

Answer 3

在头文件中，指定内部链接或使用匿名命名空间通常没有意义。

在单独编译的实现文件中，您可以使用static或匿名命名空间来避免链接级别名称冲突或依赖于实现详细信息的客户端代码。匿名命名空间允许您具有模板参数所需的外部链接，并且它还支持类定义。但最终只是个案基础上的实用性和个人偏好问题。

成员函数的

static与链接规范无关。无论如何，static成员函数都有外部链接。

Answer 4

如果您使用某些工具，

static会更好。在大多数文本编辑器中，它还具有自动缩进功能。当你不得不避免使用有用的东西时会有点伤感，因为它不能用于真正支持它的工具，但我保证你会克服它。

一个示例问题，在调试部门中给出了一些潜在的痛苦暗示：

Viewing namespaced global variables in Visual Studio debugger?

你可能不必非常努力地找到更多的问题，但是调试器问题足以让我完全放弃命名空间，所以我再也没有看过了。

我个人的建议是，对于不会永远存在的代码，可以选择使用static。与未命名的命名空间实际上是一样的，但是，对所有工具进行平均，它会得到更好的支持。从理论上讲，有一天它会彻底消失，但我很高兴公开承认，我确信那一天永远不会真正成真。与此同时，你正在为自己省一些痛苦。

什么时候在C ++中使用静态（在未命名的命名空间中）是否合适？

4 个答案: