加前缀的双冒号“：”的含义是什么？

Question

加前缀的双冒号“：”的含义是什么？我在一个必须修改的类中找到了这一行代码：::Configuration * tmpCo = m_configurationDB;//pointer to current db我不知道类名前面的双冒号到底是什么意思。如果没有，我会读到：宣布tmpCo作为指向类的对象的指针。Configuration..但这两个冒号让我很困惑。我还发现：typedef ::config::set ConfigSet;

Answer 1

这确保解析发生在全局命名空间中，而不是从当前所在的名称空间开始。例如，如果您有两个不同的类Configuration因此：

class Configuration; // class 1, in global namespacenamespace MyApp{
    class Configuration; // class 2, different from class 1
    function blah()
    {
        // resolves to MyApp::Configuration, class 2
        Configuration::doStuff(...) 
        // resolves to top-level Configuration, class 1
        ::Configuration::doStuff(...)
    }}

基本上，它允许您遍历全局命名空间，因为在本例中，您的名称可能会被另一个名称空间内的新定义所破坏。MyApp.

Answer 2

这个::运算符称为作用域解析运算符，它就是这样做的，它解析作用域.因此，通过在一个类型名的前缀加上这个前缀，它会告诉您的编译器查看该类型的全局命名空间。

例子：

int count = 0;int main(void) {
  int count = 0;
  ::count = 1;  // set global count to 1
  count = 2;    // set local count to 2
  return 0;}

Answer 3

已经有很多合理的答案了。我将加入一个类比，这可能会对一些读者有所帮助。::非常类似于文件系统目录分隔符‘/‘，在搜索您想要运行的程序的路径时。考虑：

/path/to/executable

这是非常显式的-只有在文件系统树中的确切位置上的可执行文件才能与此规范相匹配，而不管实际的路径是什么。同样的.。

::std::cout

.在C+命名空间“树”中同样显式。

与这些绝对路径相比，您可以配置良好的UNIXshell(例如，兹什)解决相对当前目录下的路径或PATH环境变量，所以如果PATH=/usr/bin:/usr/local/bin，而你“在”/tmp然后.。

X11/xterm

.很乐意跑/tmp/X11/xterm如果被发现，否则/usr/bin/X11/xterm不然的话/usr/local/bin/X11/xterm..类似地，假设您在一个名为X，并且有一个“using namespace Y“实际上，那么.

std::cout

.可以在任何一个::X::std::cout, ::std::cout, ::Y::std::cout，可能还有其他地方参数相关查找(ADL，又名Koenig查找)所以，只有::std::cout非常明确地说明了您指的是哪个对象，但幸运的是，没有一个头脑正常的人会创建自己的类/结构或名称空间，名为“std“，也没有什么叫”cout“，所以在实践中只使用std::cout都没问题。

值得注意的差异:

1)shell倾向于使用PATH，而C+在模棱两可的情况下会出现编译器错误。

2)在C+中，没有任何前导作用域的名称可以在当前命名空间中匹配，而大多数UNIXshell只能在.在PATH.

3)C+总是搜索全局命名空间(比如/含蓄地PATH).

关于名称空间与符号明示性的一般性讨论

使用绝对::abc::def::...“路径”有时有助于将您与您正在使用的任何其他名称空间隔离开来，这些名称空间是库的客户端代码也使用的内容的一部分，但实际上无法控制其内容，甚至是其他库。另一方面，它还更紧密地将您与符号的现有“绝对”位置结合在一起，并且您忽略了名称空间中隐式匹配的优点：耦合更少，代码在命名空间之间更容易移动，以及更简洁、更易读的源代码。

和很多事情一样，这是一种平衡的行为。C+标准在std::它不那么“独特”cout，程序员可能会在他们的代码中使用完全不同的东西。merge, includes, fill, generate, exchange, queue, toupper, max)。两个不相关的非标准库使用相同的标识符的几率要高得多，因为作者通常不知道或不太了解对方。库-包括C+标准库-随着时间的推移而改变它们的符号。所有这些都可能在重新编译旧代码时造成歧义，特别是在大量使用using namespace在这个空间里你能做的最糟糕的事情就是允许using namespace在标头中，可以转义标头的作用域，因此任意数量的直接和间接客户端代码无法自行决定使用哪些命名空间以及如何管理歧义。

所以，一个领导::是C+程序员工具箱中的一个工具，可以主动消除已知冲突的歧义，并/或消除未来歧义的可能性.