3.4.1 Unqualified name lookup

According to C++ standard :-

The name lookup rules apply uniformly to all names (including typedef-names (7.1.3), namespace-names (7.3), concept-names (14.9), concept-map-names (14.9.2), and class-names (9.1)) wherever the grammar allows such names in the context discussed by a particular rule.

Name lookup rules apply Before Overload resolution takes place?

There must be some reason behind that I do not understand.

Following example is from Book C++ in a Nutshell :-

void func(int i)
{
  std::cout << "int: " << i <&l开发者_StackOverflowt; '\n';
}



namespace N 
{
  void func(double d)
  {
    std::cout << "double: " << std::showpoint << d << '\n';
  }

  void call_func(  )
  {
    // Even though func(int) is a better match, the compiler finds
    // N::func(double) first.
    func(3);
  }
}

If I am working in namespace N.
I just wrote a function called func() then I write some code to call this new function. It would seem counter intuitive for it to choose a function from another namespace before it used the function I just wrote.

Now consider the situation is reversed.

(ie. It uses overload resolution)

I write a function bob(double). It works perfectly as there is no conflict with a `bob(double) in the global namespace. I write my code and the application works perfectly.

A year later somebody writes a function bob(int) in the global namespace and re-compiles the application. Suddenly with no change in my code. All my calls to bob(5) have been redirected to the bob(int) in the global namespace.

This is highly undesirable way for the application to work.

Yes. Name lookup attempts to find all names visible at the point of usage. Once the entire superset of declarations of the name is built up, overload resolution is done in case the name is determined to be the name of a function. The name lookup ends if a matching name is found else fails.

If name lookup succeeds and if the name is determined to the name of a function, overload resolution is done to find the best viable function if any. Subsequently acess check is done to find out if the name is indeed accessible in the context of the access.

Note that visibility of the name is important for name lookup and not accessibility.

Name-look up operates before the overload resolution. For the compiler to know 'which function is called', it operates in this order

• Name look-up
• Template Arguments Resolution
• Overload Resolution
• Access Control
• Virtual Functions

For the why, you may refer to https://publib.boulder.ibm.com/infocenter/lnxpcomp/v8v101/index.jsp?topic=%2Fcom.ibm.xlcpp8l.doc%2Flanguage%2Fref%2Fcplr315.htm and to Channel 9 courses http://channel9.msdn.com/Series/C9-Lectures-Stephan-T-Lavavej-Core-C-/Stephan-T-Lavavej-Core-C-1-of-n .

In fact, Overload-Resolution comes down to the choice of the most viable function, that is the search for the most appropriate function declaration corresponding to a function call.

This search based on the number of function parameters, and then on the 'implicit conversion sequence' occurs in a set of pre-selected functions. If call to be resolved is f(), this set contains all functions with name f() that are visible from a certain point in the code. This set is determined by Name Look-Up.