Name lookup doubt

[Srini]

I was reading the "Exceptiona l C++" of Herb Sutter. In an example, he
mentions the following.

// In some library header:
namespace N { class C{}; }
int operator+(int i, N::C) { return i+1; }
// A mainline to exercise it:
#include <numeric>
int main()
{
N::C a[10];
std::accumulate (a, a+10, 0);
}

He explains what the compiler does inside std::accumulate . There'd be a
call to an operator+ that takes an int and an N::C - "First, the
compiler looks in the immediate scope, in this case the scope of
namespace std, and makes a list of all functions it can find that are
named operator+() (regardless of whether they are accessible or even
take the right number of parameters). Only if it does not find any at
all does it then continue outward into the next enclosing namespace
outside std, which happens to be the global scope - until it eventually
runs out of scopes, without having found a function with the right name
or else finds a scope that contains at least one candidate function."
He then says that the code example above, may or may not compile
depending on whether the implementation of standard header numeric
a) declares an operator+() OR
b) includes any other standard header that does so

The solution to this, he says, is to put the operator+() inside
namespace N

namespace N {
class C{};
int operator+(int i, N::C) { return i+1; }
}

This would compile on any implementation because of Koenig lookup. My
doubt is whether Koenig lookup precedes the name look-up procedure he
explained before - that is, going from current scope outwards,
searching for names. What is the order in which namespaces are searched
for names taking even Koenig lookup into account.

Thanks in advance
Regards,
Srini

[Maxim Yegorushkin]

Srini wrote:

I was reading the "Exceptiona l C++" of Herb Sutter. In an example, he
mentions the following.

// In some library header:
namespace N { class C{}; }
int operator+(int i, N::C) { return i+1; }
// A mainline to exercise it:
#include <numeric>
int main()
{
N::C a[10];
std::accumulate (a, a+10, 0);
}

He explains what the compiler does inside std::accumulate . There'd be a
call to an operator+ that takes an int and an N::C - "First, the
compiler looks in the immediate scope, in this case the scope of
namespace std, and makes a list of all functions it can find that are
named operator+() (regardless of whether they are accessible or even
take the right number of parameters). Only if it does not find any at
all does it then continue outward into the next enclosing namespace
outside std, which happens to be the global scope - until it eventually
runs out of scopes, without having found a function with the right name
or else finds a scope that contains at least one candidate function."
He then says that the code example above, may or may not compile
depending on whether the implementation of standard header numeric
a) declares an operator+() OR
b) includes any other standard header that does so

The solution to this, he says, is to put the operator+() inside
namespace N

namespace N {
class C{};
int operator+(int i, N::C) { return i+1; }
}

This would compile on any implementation because of Koenig lookup. My
doubt is whether Koenig lookup precedes the name look-up procedure he
explained before - that is, going from current scope outwards,
searching for names. What is the order in which namespaces are searched
for names taking even Koenig lookup into account.

It does not matter whether Koening lookup or a version of if that
applies also to non operators - ADL, happens before or after ordinary
lookup, because the set of viable functions is a union of those found
by ordinary lookup and those found by ADL.

§3.4.2/2a:

If the ordinary unqualified lookup of the name finds the declaration of
a class member function, the associated namespaces and classes are not
considered. Otherwise the set of declarations found by the lookup of
the function name is the union of the set of declarations found using
ordinary unqualified lookup and the set of declarations found in the
namespaces and classes associated with the argument types.