cpp/language/unqualified lookup

For an unqualified name, that is a name that does not appear to the right of a scope resolution operator, name lookup examines the as described below, until it finds at least one declaration of any kind, at which time the lookup stops and no further scopes are examined. (Note: lookup from some contexts skips some declarations, for example, lookup of the name used to the left of ignores function, variable, and enumerator declarations, lookup of a name used as a base class specifier ignores all non-type declarations)

For the purpose of unqualified name lookup, all declarations from a namespace nominated by a appear as if declared in the nearest enclosing namespace which contains, directly or indirectly, both the using-directive and the nominated namespace.

Unqualified name lookup of the name used to the left of the function-call operator (and, equivalently, operator in an expression) is described in.

File scope
For a name used in global (top-level namespace) scope, outside of any function, class, or user-declared namespace, the global scope before the use of the name is examined:

Namespace scope
For a name used in a user-declared namespace outside of any function or class, this namespace is searched before the use of the name, then the namespace enclosing this namespace before the declaration of this namespace, etc until the global namespace is reached.

Definition outside of its namespace
For a name used in the definition of a namespace-member variable outside the namespace, lookup proceeds the same way as for a name used inside the namespace:

Non-member function definition
For a name used in the definition of a function, either in its body or as part of default argument, where the function is a member of user-declared or global namespace, the block in which the name is used is searched before the use of the name, then the enclosing block is searched before the start of that block, etc, until reaching the block that is the function body. Then the namespace in which the function is declared is searched until the definition (not necessarily the declaration) of the function that uses the name, then the enclosing namespaces, etc.

Class definition
For a name used anywhere in (including base class specifiers and nested class definitions), except inside a member function body, a default argument of a member function, exception specification of a member function, or default member initializer, where the member may belong to a nested class whose definition is in the body of the enclosing class, the following scopes are searched: @a@ the body of the class in which the name is used until the point of use, @b@ the entire body of its base class(es), recursing into their bases when no declarations are found, @c@ if this class is, the body of the enclosing class until the definition of this class and the entire body of the base class(es) of the enclosing class, @d@ if this class is, or nested within a local class, the block scope in which the class is defined until the point of definition, @e@ if this class is a member of a namespace, or is nested in a class that is a member of a namespace, or is a local class in a function that is a member of a namespace, the scope of the namespace is searched until the definition of the class, enclosing class, or function; lookup continues to the namespaces enclosing that one until the global scope.

For a declaration, the lookup to determine whether it refers to a previously declared entity proceeds as above except that it stops after the innermost enclosing namespace.

Injected class name
For the name of a class or class template used within the definition of that class or template or derived from one, unqualified name lookup finds the class that's being defined as if the name was introduced by a member declaration (with public member access). For more detail, see.

Member function definition
For a name used inside a member function body, a default argument of a member function, exception specification of a member function, or a default member initializer, the scopes searched are the same as in class definition, except that the entire scope of the class is considered, not just the part prior to the declaration that uses the name. For nested classes the entire body of the enclosing class is searched.


 * Either way, when examining the bases from which the class is derived, the following rules, sometime referred to as dominance in virtual inheritance, are followed:


 * Unqualified name lookup that finds static members of, nested types of , and enumerators declared in is unambiguous even if there are multiple non-virtual base subobjects of type  in the inheritance tree of the class being examined:

Friend function definition
For a name used in a function definition inside the body of the class that is granting friendship, unqualified name lookup proceeds the same way as for a member function. For a name used in a function which is defined outside the body of a class, unqualified name lookup proceeds the same way as for a function in a namespace.

Friend function declaration
For a name used in the declarator of a function declaration that friends a member function from another class, if the name is not a part of any template argument in the  identifier, the unqualified lookup first examines the entire scope of the member function's class. If not found in that scope (or if the name is a part of a template argument in the declarator identifier), the lookup continues as if for a member function of the class that is granting friendship.

Default argument
For a name used in a in a function declaration, or name used in the  part of a  of a constructor, the function parameter names are found first, before the enclosing block, class, or namespace scopes are examined:

Static data member definition
For a name used in the definition of a, lookup proceeds the same way as for a name used in the definition of a member function.

Enumerator declaration
For a name used in the initializer part of the, previously declared enumerators in the same enumeration are found first, before the unqualified name lookup proceeds to examine the enclosing block, class, or namespace scope.

Catch clause of a function-try block
For a name used in the catch-clause of a, lookup proceeds as if for a name used in the very beginning of the outermost block of the function body (in particular, function parameters are visible, but names declared in that outermost block are not)

Overloaded operator
For an used in expression (e.g.,  used in ), the lookup rules are slightly different from the operator used in an explicit function-call expression such as : when parsing an expression, two separate lookups are performed: for the non-member operator overloads and for the member operator overloads (for the operators where both forms are permitted). Those sets are then merged with the built-in operator overloads on equal grounds as described in. If explicit function call syntax is used, regular unqualified name lookup is performed:

Template definition
For a used in a template definition, unqualified name lookup takes place when the template definition is examined. The binding to the declarations made at that point is not affected by declarations visible at the point of instantiation. For a used in a template definition, the lookup is postponed until the template arguments are known, at which time  examines function declarations  that are visible from the template definition context as well as in the template instantiation context, while non-ADL lookup only examines function declarations  that are visible from the template definition context (in other words, adding a new function declaration after template definition does not make it visible except via ADL). The behavior is undefined if there is a better match with external linkage in the namespaces examined by the ADL lookup, declared in some other translation unit, or if the lookup would have been ambiguous if those translation units were examined. In any case, if a base class depends on a template parameter, its scope is not examined by unqualified name lookup (neither at the point of definition nor at the point of instantiation).

Note: see for the reasoning and implications of this rule.