在 C++ 中，我在哪里放置常量字符串：静态类成员或匿名命名空间？答案

【问题标题】：Where do I put constant strings in C++: static class members or anonymous namespaces?在 C++ 中，我在哪里放置常量字符串：静态类成员或匿名命名空间？
【发布时间】：2011-01-28 18:18:12
【问题描述】：

我需要定义一些仅由一个类使用的常量字符串。看起来我有三个选择：

将字符串直接嵌入到使用它们的位置。

将它们定义为类的私有静态常量成员：

//A.h  
class A {  
private:  
   static const std::string f1;  
   static const std::string f2;  
   static const std::string f3;  
};  

//A.cpp  
const std::string f1 = "filename1";  
const std::string f2 = "filename2";  
const std::string f3 = "filename3";  

//strings are used in this file

在 cpp 文件的匿名命名空间中定义它们：

//A.cpp  
namespace {  
  const std::string f1 = "filename1";  
  const std::string f2 = "filename2";  
  const std::string f3 = "filename3";  
}  

//strings are used in this file

鉴于这些选项，您会推荐哪一个？为什么？谢谢。

【问题讨论】：

请注意，如果您在 main 启动之前调用使用来自其他翻译单元的这些字符串的函数，这是很危险的：该函数可能会在字符串对象创建之前访问它们。出于这个原因，我会摆脱 const std::string 对象，并为此使用char const f1[] = "filename";。
@litb：您似乎是说在这种情况下使用原始类型 char 比使用字符串对象更安全？我可以知道这背后的原因吗？
@jasonline，正如我在评论中所说：字符串是复杂的对象，并在程序启动期间初始化。如果你在不同的翻译单元中有多个这样的对象，你不知道它们的创建顺序，所以如果你互相引用，你可能会引用一个尚未构造的字符串。 char const[] 变体并非如此。

标签： c++ string static namespaces anonymous

【解决方案1】：

如果字符串打算被类的用户看到，请将它们放入类中。否则，将它们隐藏在实现文件的未命名命名空间中。

【讨论】：

【解决方案2】：

如果它们仅在单个文件中使用，则无需通过将它们包含在头文件中来将它们暴露给外界。

如果它们被使用并且总是只在一个地方使用，那么真的没有理由不把它们写成需要使用的文字。

如果它们在 cpp 中的多个位置使用，我会选择匿名命名空间。

您没有提到的另一个选项是将它们定义为 cpp 中的静态变量。这在某种程度上等同于匿名命名空间选项，并且比 C++ 更像 C。

【讨论】：

【解决方案3】：

类的静态成员。

如果它们被一个类在多个地方使用，则通常更容易使事物井井有条 - 并且稍后找到您定义所有内容的位置 - 如果您将它们定义在使用它们的类中。就地定义它们使它们难以定位和以后修改。而且我会选择匿名命名空间上的特定类，以便更清晰的类定义和使用。

【讨论】：

【解决方案4】：

在这三个选项中，您真正应该避免的唯一一个是＃1。不要在你的代码中使用魔法 cookie。通过将常量放在命名空间或类中，您可以更轻松地在未来扩展和维护您的代码。

如果您的常量本质上是全局的，那么在 2 到 3 之间，这无关紧要。重要的是你选择一个并坚持下去。但是，如果您有适用于特定类的常量，那么它们应该是该类的一部分。

就个人而言，我会为大多数事情使用命名空间。

【讨论】：

【解决方案5】：

我会将它们放在 CPP 文件中的匿名命名空间中。它使它们对实现是私有的，同时使其对作为实现一部分的非成员函数可见（例如operator<<）。

【讨论】：

感谢您的评论。我也倾向于这个选项。这些字符串最想保持不变。但是，如果后来我决定更改其中一个文件名，我可以在那里轻松地做到这一点，而不必担心重新编译包含头文件的所有内容。
值得注意的是，即使您在类中将它们定义为静态常量，实际文本仍然必须在实现文件中。因此，更改文件名不需要重新编译除该文件之外的任何内容。
你是对的，丹尼斯。在添加/删除这些常量时，它只会在编译方面有所不同。修改它们应该是一样的。
参考原始问题，匿名命名空间是不必要的，因为在文件范围内声明的 const 默认情况下具有内部链接。如果您不担心名称冲突，那么只需摆脱匿名命名空间即可。

【解决方案6】：

我认为真正的问题是：这些字符串真的只在实现类时在内部使用，还是在其他地方使用。

真正的挑剔，我会尽量保持类的接口尽可能干净，所以如果文件名字符串不应该对“外部”世界感兴趣。我只会将它们隐藏在 .cpp 文件中。在这种情况下，我认为我不会打扰命名空间，而只是保持“静态”（即 .cpp 文件的内部）。

【讨论】：

【解决方案7】：

如果只在类的.cpp文件中使用，则不需要使用任何类型的命名空间，简单地说：

const std::string f1 = "filename1";  
const std::string f2 = "filename2";  
const std::string f3 = "filename3";

过度使用命名空间似乎是新事物 - 我个人看不出吸引力。

【讨论】：

但是如果其他编译单元中存在名称 f1、f2 等，则可能会导致链接器错误。这就是存在匿名命名空间的原因。
这些定义和匿名命名空间有什么区别吗？在我看来，它们被隐式定义为“静态”。
@Nemanja 不，不会。在命名空间范围内声明的 const 对象是翻译单元的本地对象。
@Neil。你说的对。在 C++ 中，常量值默认为内部链接。
@Neil：匿名命名空间和你的答案有什么区别，不使用命名空间？

【解决方案8】：

不管你怎么做，有一点需要注意：我不建议使用静态 std::string 对象，而是使用静态 char*。其原因是由于初始化顺序的潜在问题。假设您有一个类的静态实例，其构造函数引用字符串A::f1。不能保证A::f1 已经构建好了，你会遇到崩溃，或者更糟的是，没有崩溃，而是伪造的数据。

跟踪初始化顺序错误可能非常讨厌，在一个项目中一切可能看起来都很好，但是您可能会使用相同的库构建另一个项目，链接顺序的细微差异会导致此错误神秘地出现。

【讨论】：

【解决方案9】：

只需在实现文件的文件范围内使用 const 字符串，匿名命名空间不必将其仅限于该类。

C++ 003 StandardC.1.2 第 3 条：基本概念

Change: A name of ﬁle scope that is explicitly declared const, and not explicitly declared extern, has internal linkage, while in C it would have external linkage

注意：匿名命名空间确实有助于减少命名冲突。

【讨论】：