当内部作用域不起作用时，为什么编译器不采用命名空间名称？

Question

我认为我非常了解名称查找（在观看了几个有关它的视频并阅读了很多内容之后），但我只是遇到了这种情况：

#include <iostream>

namespace test{

  struct Id
  {};

  void do_something( const Id& ){  std::cout << "Hello, World!" << std::endl; }

  class Test
  {
  public:

    void do_something() { std::cout << "WTF!" << std::endl;  }

    void run()
    {
      Id id;
      do_something( id ); // doesn't compile
    }

  };

}

int main()
{
    test::Test my_test;
  my_test.run();
}

指出的行不编译（在 GCC4.8 和 VC11U2 上），因为它尝试使用成员函数 test::Test::do_something() 而不是名称空间范围的 test::do_something( const Id& )，这似乎是唯一可能的候选者。

显然，成员函数名称隐藏了命名空间范围的名称，这让我感到惊讶，因为我记得在其他上下文中使用几乎相似的代码而没有产生此问题（但最终条件可能会非常不同）。

我的问题是：这些编译器是否符合标准？

（不幸的是，通过阅读标准文档很难理解名称查找，所以我需要专家确认）

Answer 1

我的问题是：这些编译器是否符合标准？

是的。在重载决议决定哪些函数是可行候选函数（包括检查参数的数量）之前，编译器首先必须进行名称查找，以找到所有候选函数，可行的和不可行的。在您的示例中，名称查找在找到成员 do_something() 后停止，因此重载决议永远没有机会确定命名空间范围是否可行。

3.4.1 [basic.lookup.unqual]/1：“在 3.4.1 中列出的所有情况下，将按照每个相应类别中列出的顺序搜索范围以查找声明；名称查找会尽快结束作为名称的声明。”

3.4.1 [basic.lookup.unqual] 第 8 段列出了搜索名称的上下文，甚至还有一个示例可以准确回答您的问题。 Test 的范围在封闭的命名空间之前被搜索，并且正如第 1 段所说，“一旦找到名称的声明，名称查找就结束”。

Answer 2

一门语言越是努力为一个结构找到一个有效的解释，一个错字或其他类似错误就越有可能导致编译器找到一个有效但错误的含义。编译器假设如果foo 在某个范围内定义，并且该范围内的代码使用foo，则程序员打算让代码使用在该范围内定义的foo。如果程序员试图用 foo 做一些其内部范围定义不允许的事情，那么很有可能出现以下情况之一：

• 程序员打算做一些稍微不同的操作，这在内部 foo 上是有效的。除非程序员指定编译器，否则不能期望编译器知道程序员的意图。
• 程序员打算执行指定的操作，但没有意识到内部foo 不能支持它，因此必须找到内部foo 可以支持的一些其他操作或操作序列。同样，除非程序员指出如何正确使用foo，否则不能期望编译器生成好的代码。
• 程序员打算对外部 foo 执行相关操作，但拒绝明确表示。如果编译器想猜测这就是程序员的意思，它可以生成具有这种行为的代码。

只有当程序员的意图是#3 时，编译器才可能生成行为符合预期的代码。然而，更有可能的是，程序员真正想要的是#1 或#2。如果编译器即使假设#3 会产生有效 代码也拒绝编译代码，那么将发现上述任何错误并因此可以被纠正。相比之下，如果编译器尽可能假设 #3，那么如果程序员真的打算 #1 或 #2 问题，直到代码运行并表现出与设计相反的行为才会显现出来。

顺便说一句，如果我有我的 druthers，我会将此原则应用于 .NET 语言中的区分大小写，不仅禁止以与定义不一致的方式写入任何标识符（如 C# 所做的，但 vb. net)，但使用的任何标识符仅在大写/小写方面与内部范围内的标识符不同。例如：

class foo
{
  int x;
  void bar()
  {
    int X=2;
    x=4; // ****
    return X;
  }
}

鉴于上面的代码，C# 会猜测带星号的行是用来写字段的；给定类似的代码，vb.net 会假设它打算编写局部变量。就个人而言，我不喜欢这两种假设。 “准确地说出你的意思”的原则向我建议，编译器应该要求程序员说 this.x=4; 或 X=4;，这两者都不能被解读为具有错误的含义。

Answer 3

这根本不是查找问题。关键是lookup在在重载决议启动之前完成。当编译器看到do_something时，它会执行lookup来弄清楚它的含义，它发现它是一个函数，这反过来又激活了ADL寻找其他潜在的过载。然后查找完成并开始重载解析。当重载解决失败时。

Answer 4

编译器将收集所有“候选名称”，除非涉及 ADL，否则它们将来自同一范围，然后尝试选择最佳匹配（如果可用）。在任何情况下，失败的匹配都不会导致它尝试从备用范围中查找其他候选名称。

这与编译器首先进行重载解析然后检查成员的公共/私有以查看它是否实际可访问的方式非常相似。

g++ 有一个方便的-Wshadow 选项来寻找阴影（不过我不确定它是否会特别警告这一点）。

Answer 5

不幸的是，通过阅读标准文档很难理解名称查找，所以我需要专家确认

无论如何我都不是专家，但我是这样理解标准的名称查找规则的。

两个例子：

void foo(int);

namespace associated
{
    struct bee {};
    void flower(bee);
}

namespace bar
{
    void foo();
    void flower();

    void test()
    {
        foo(42);                   // (A)
        flower(associated::bee()); // (B)
    }
}

int main()
{
    bar::test();
}

(A) 无法编译，因为 [basic.lookup.unqual]: "name lookup 在找到该名称的声明后立即结束"

(B) 确实编译，因为 ADL； associated 是一个关联的命名空间。

但是，有 [basic.lookup.argdep]/3:

令 X 为非限定查找 (3.4.1) 生成的查找集，让 Y 为参数相关查找生成的查找集（定义如下）。如果 X 包含

• 类成员的声明，或
• 不是 using 声明的块范围函数声明，或
• 既不是函数也不是函数模板的声明

那么 Y 为空。否则 Y 是在与参数类型关联的命名空间中找到的一组声明，如下所述。通过名称查找找到的声明集是 X 和 Y 的并集。

第一点适用于您的示例。因此，我认为是的，拒绝您的示例的编译器符合标准。