In the C++ programming language, argument-dependent lookup (ADL), or argument-dependent name lookup, applies to the lookup of an unqualified function name depending on the types of the arguments given to the function call. This behavior is also known as Koenig lookup, as it is often attributed to Andrew Koenig, though he is not its inventor.
During argument-dependent lookup, other namespaces not considered during normal lookup may be searched where the set of namespaces to be searched depends on the types of the function arguments. Specifically, the set of declarations discovered during the ADL process, and considered for resolution of the function name, is the union of the declarations found by normal lookup with the declarations found by looking in the set of namespaces associated with the types of the function arguments.
An example of ADL looks like this:
Even though the function is not in namespace <code>foo</code>, nor is namespace <code>foo</code> in scope, the function is found because of the declared types of the actual arguments in the function call statement.
A common pattern in the C++ Standard Library is to declare overloaded operators that will be found in this manner. For example, this simple Hello World program would not compile if it weren't for ADL:
Using <code><<</code> is equivalent to calling <code>operator<<</code> without the <code>std::</code> qualifier. However, in this case, the overload of operator<< that works for <code>string</code> is in the <code>std</code> namespace, so ADL is required for it to be used.
The following code would work without ADL (which is applied to it anyway):
It works because the output operator for integers is a member function of the <code>std::ostream</code> class, which is the type of <code>cout</code>. Thus, the compiler interprets this statement as
which it can resolve during normal lookup. However, consider that e.g. the <code>const char*</code> overloaded <code>operator<<</code> is a non-member function in the <code>std</code> namespace and, thus, requires ADL for a correct lookup:
The <code>std</code> namespace overloaded non-member <code>operator<<</code> function to handle strings is another example:
As Koenig points out in a personal note, without ADL the compiler would indicate an error stating it could not find <code>operator<<</code> as the statement doesn't explicitly specify that it is found in the <code>std</code> namespace.
Functions found by ADL are considered part of a class's interface. In the C++ Standard Library, several algorithms use unqualified calls to <code>swap</code> from within the <code>std</code> namespace. As a result, the generic <code></code> function is used if nothing else is found, but if these algorithms are used with a third-party class, <code>Foo</code>, found in another namespace that also contains <code>swap(Foo&, Foo&)</code>, that overload of <code>swap</code> will be used.
While ADL makes it practical for functions defined outside of a class to behave as if they were part of the interface of that class, it makes namespaces less strict and so can require the use of fully qualified names when they would not otherwise be needed. For example, the C++ standard library makes extensive use of unqualified calls to <code></code> to swap two values. The idea is that then one can define an own version of <code>swap</code> in one's own namespace and it will be used within the standard library algorithms. In other words, the behavior of
may or may not be the same as the behavior of
(where <code>a</code> and <code>b</code> are of type <code>foo::Bar</code>) because if <code>foo::swap(foo::Bar&, foo::Bar&)</code> exists, the second of the above examples will call it while the first will not. Furthermore, if for some reason both <code>foo::swap(foo::Bar&, foo::Bar&)</code> and <code>std::swap(foo::Bar&, foo::Bar&)</code> are defined, then the first example will call <code>std::swap(foo::Bar&, foo::Bar&)</code> but the second will not compile because <code>swap(a, b)</code> would be ambiguous.
In general, over-dependence on ADL can lead to semantic problems. If one library, <code>lib1</code>, expects unqualified calls to <code>foo(T)</code> to have one meaning and another library, <code>lib2</code> expects it to have another, then namespaces lose their utility. If, however, <code>lib1</code> expects <code>lib1::foo(T)</code> to have one meaning and <code>lib2</code> does likewise, then there is no conflict, but calls to <code>foo(T)</code> would have to be fully qualified (i.e. <code>lib1::foo(x)</code> as opposed to <code>using lib1::foo; foo(x);</code>) lest ADL get in the way.