什么是“参数相关查找” （又名 ADL，或“Koenig Lookup”）？

Question

关于什么是参数依赖查找有哪些好的解释？许多人也将其称为 Koenig Lookup。

我最好想知道：

• 为什么这是一件好事？
• 为什么这是一件坏事？
• 它是如何运作的？

Answer 1

参数依赖查找 (ADL)，有时称为 Koenig Lookup，描述了 C++ 编译器如何查找非限定名称。

C++11 标准 § 3.4.2/1 规定：

当函数调用（5.2.2）中的后缀表达式是非限定 ID 时，可以搜索在通常的非限定查找（3.4.1）期间未考虑的其他命名空间，并且在这些命名空间中，命名空间范围的友元可以找到不可见的函数声明（11.3）。对搜索的这些修改取决于参数的类型（对于模板模板参数，模板的命名空间
论证）。

简而言之，Nicolai Josuttis 指出¹：

如果在函数的命名空间中定义了一个或多个参数类型，则不必限定函数的命名空间。

一个简单的代码示例：

namespace MyNamespace
{
    class MyClass {};
    void doSomething(MyClass) {}
}

MyNamespace::MyClass obj; // global object


int main()
{
    doSomething(obj); // Works Fine - MyNamespace::doSomething() is called.
}

在上面的示例中，既没有 using 声明，也没有 using 指令，但编译器仍然正确识别非限定名称 doSomething() 作为通过应用 ADL 在命名空间 MyNamespace 中声明的函数。

它是如何运作的？

该算法告诉编译器不仅要查看本地范围，还要查看包含参数类型的命名空间。因此，在上面的代码中，编译器发现对象 obj（函数 doSomething() 的参数）属于命名空间 MyNamespace.因此，它会查看该名称空间来定位 doSomething() 的声明。

ADL有什么优势？

正如上面的简单代码示例所示，ADL 为程序员提供了便利性和易用性。如果没有 ADL，程序员就会产生开销，需要重复指定完全限定名称，或者使用大量 using 声明。

为什么ADL受到批评？

过度依赖 ADL 可能会导致语义问题，有时会让程序员措手不及。

考虑 std::swap 的示例，其中是交换两个值的标准库算法。使用 ADL 时，必须谨慎使用此算法，因为：

std::swap(obj1,obj2);

可能不会显示与以下行为相同的行为：

using std::swap;
swap(obj1, obj2);

使用 ADL，调用哪个版本的 swap 函数将取决于传递给的参数的名称空间它。

如果存在命名空间 A，并且如果 A::obj1、A::obj2 和 A::swap() 存在，那么第二个示例将导致调用 A::swap()，这可能不是用户想要的。

此外，如果由于某种原因 A::swap(A::MyClass&, A::MyClass&) 和 std::swap(A::MyClass&, A::MyClass& ;) 被定义，那么第一个示例将调用 std::swap(A::MyClass&, A::MyClass&) 但第二个示例将无法编译，因为swap(obj1, obj2) 是不明确的。

冷知识：

为什么有时称为“Koenig 查找”？

因为它是由前 AT&T 和贝尔实验室研究员和程序员 Andrew Koenig，尽管柯尼格本人对此提出异议在2012 年的一篇博文：

我的名字与参数相关查找相关的原因是，虽然我没有发明这个想法，但我确实认识到命名空间的引入会导致严重的问题，需要 ADL 或类似的东西来解决。< /p>

进一步阅读：

• 赫伯·萨特 (Herb Sutter) 在 GotW 上的名字查找

• 标准 C++03/11 [基本。 lookup.argdep]：3.4.2 参数相关名称查找。

---

_{**¹** The definition of ADL is as defined in Josuttis' book, *The C++ Standard Library: A Tutorial and Reference*.}

Answer 2

在 Koenig Lookup 中，如果调用函数时未指定其命名空间，则也会在定义参数类型的命名空间中搜索函数名称。这就是为什么它也被称为参数依赖名称查找，简而言之就是ADL。

正是因为有了Koenig Lookup，我们才能这样写：

std::cout << "Hello World!" << "\n";

否则，我们就得这样写：

std::operator<<(std::operator<<(std::cout, "Hello World!"), "\n");

这实在是打字太多了，而且代码看起来真的很难看！

换句话说，在没有 Koenig Lookup 的情况下，即使是 Hello World 程序看起来也很复杂。

Answer 3

也许最好从“为什么”开始，然后再讨论“如何”。

当引入命名空间时，我们的想法是在命名空间中定义所有内容，以便单独的库不会相互干扰。然而，这给运营商带来了一个问题。例如，请看下面的代码：

namespace N
{
  class X {};
  void f(X);
  X& operator++(X&);
}

int main()
{
  // define an object of type X
  N::X x;

  // apply f to it
  N::f(x);

  // apply operator++ to it
  ???
}

当然，您可以编写 N::operator++(x)，但这会破坏运算符重载的全部意义。因此，必须找到一种解决方案，允许编译器找到 operator++(X&)，尽管它不在范围内。另一方面，它仍然不应该找到在另一个不相关的命名空间中定义的另一个 operator++ ，这可能会使调用不明确（在这个简单的示例中，您不会得到歧义，但在更复杂的示例中，你可能会）。解决方案是参数相关查找 (ADL)，这样称呼是因为查找取决于参数（更准确地说，取决于参数的类型）。由于该方案是由 Andrew R. Koenig 发明的，因此通常也称为 Koenig 查找。

技巧在于，对于函数调用，除了正常的名称查找（在使用时在范围内查找名称）之外，还会在给定函数的任何参数的类型范围中进行第二次查找。因此，在上面的示例中，如果您在 main 中编写 x++，它不仅会在全局范围内查找 operator++，还会在 x 类型所在的范围内查找 operator++，N::X，被定义，即在命名空间N中。在那里它找到了一个匹配的operator++，因此x++就可以工作了。但是，将找不到在另一个命名空间（例如 N2）中定义的另一个 operator++。由于 ADL 不限于运算符，您还可以在 main() 中使用 f(x) 代替 N::f(x) 。

Answer 4

在我看来，并非所有事情都是好的。人们，包括编译器供应商，一直在侮辱它，因为它有时会出现不幸的行为。

ADL 负责对 C++11 中的 for-range 循环进行重大修改。要理解为什么 ADL 有时会产生意想不到的效果，请考虑不仅考虑定义参数的命名空间，还考虑参数的模板参数、函数类型的参数类型/这些参数的指针类型的参数类型，等等。

使用 boost 的示例

std::vector<boost::shared_ptr<int>> v;
auto x = begin(v);

如果用户使用 boost.range 库，这会导致歧义，因为找到了两个 std::begin （通过 ADL 使用 std::vector）并且找到了 boost::begin （通过 ADL 使用 boost::shared_ptr）。