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

在Koenig Lookup中，如果调用一个函数时没有指定其命名空间，那么函数的名称也会在定义参数类型的命名空间中搜索。这就是为什么它也被称为 Argument-Dependent name Lookup，简称 ADL。

正是因为 Koenig Lookup，我们可以这样写：

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

否则，我们将不得不写：

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

这真的是打字太多了，代码看起来真的很丑！

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

Koenig Lookup，或参数相关查找，描述了编译器如何在 C++ 中查找非限定名称。

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

当函数调用 （5.2.2） 中的 postfix-expression 是 unqualified-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.
}

在上面的例子中，既没有 -declaration 也没有 -directive，但编译器仍然通过应用 Koenig 查找正确地将非限定名称标识为命名空间中声明的函数。usingusingdoSomething()MyNamespace

它是如何工作的？

该算法告诉编译器不仅要查看局部范围，还要查看包含参数类型的命名空间。因此，在上面的代码中，编译器发现作为函数参数的对象属于命名空间。因此，它会查看该命名空间以找到 的声明。objdoSomething()MyNamespacedoSomething()

Koenig 查找的优势是什么？

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

为什么批评 Koenig 查找？

过度依赖 Koenig 查找会导致语义问题，有时会让程序员措手不及。

以 std：：swap 为例，它是一种用于交换两个值的标准库算法。使用 Koenig 查找时，使用此算法时必须谨慎，因为：

std::swap(obj1,obj2);

可能不会表现出与以下行为相同的行为：

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

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

如果存在命名空间 ，并且 ， ， 和 存在，则第二个示例将导致对 的调用，这可能不是用户想要的。AA::obj1A::obj2A::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 lookup”？

因为它是由前AT&T和贝尔实验室研究员和程序员安德鲁·科尼希（Andrew Koenig）设计的。

延伸阅读：

• Herb Sutter 在 GotW 上的名字查找

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

---

_{**¹** Koenig 查找的定义在 Josuttis 的书《*C++ 标准库：教程和参考》中定义。}

也许最好从为什么开始，然后才去怎么做。

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

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
  ???
}

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

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

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

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

使用 boost 的示例

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

如果用户使用 boost.range 库，这会导致歧义，因为两者都被找到（由 ADL 使用 ）和被找到（由 ADL 使用 ）。std::beginstd::vectorboost::beginboost::shared_ptr