[basic.lookup]/1:
The name lookup rules apply uniformly to all names (including typedef-names (10.1.3), namespace-names
(10.3), and class-names (12.1)) wherever the grammar allows such names in the context discussed by a
particular rule. Name lookup associates the use of a name with a set of declarations (6.1) of that name. The
declarations found by name lookup shall either all declare the same entity or shall all declare functions; in the
latter case, the declarations are said to form a set of overloaded functions (16.1). Overload resolution (16.3)
takes place after name lookup has succeeded. The access rules (Clause 14) are considered only once name
lookup and function overload resolution (if applicable) have succeeded. Only after name lookup, function
overload resolution (if applicable) and access checking have succeeded are the attributes introduced by the
name’s declaration used further in expression processing (Clause 8).
What are those attributes introduced by the names´s declaration?
This sentence is visible in the N1638 - C++ Working Draft from April 2004, so it doesn't refer specifically to attributes of the form [[...]], which were introduced to the standard by N2761 - Towards support for attributes in C++
(Revision 6) in 2008.
[basic.lookup]/1
Only after name lookup, function overload resolution (if applicable) and access checking have succeeded are the attributes introduced by the name’s declaration used further in expression processing (clause 5).
Also [basic.def]/1
A declaration (clause 7) introduces names into a translation unit or redeclares names introduced by previous declarations. A declaration specifies the interpretation and attributes of these names.
From the above, and looking at the five other occurrences of 'attribute' in that paper, it appears to me that 'attribute' just means "information about the name". So in this case, things like extern, friend, the body of a function definition, and anything else you can say about a name in a declaration, that wasn't part of determining the interpretation of a name.
Since C++11 this would also include "generalised attributes" in the form [[..]]. There's a hint here, N2761 didn't introduce 'attributes', it just gave us a generalised syntax for them.
Function parameters, conversely, would not be 'attributes' in this sense, as the interpretation of the function name involves the parameters as part of overload resolution. The return type would be an attribute, since we don't look at it until we know what the name means, and which overload we've chosen.
In a slightly-more-standardese sense, I think you can say that the 'specifiers' are attributes, while the 'declarators' specify the interpretation of a name.
Pratically, I would say (without checking for a more-specific rule) that this is the rule that requires that deleted functions survive all the way through the lookup and name resolution process, and then fail the compilation.
Otherwise, a crafty compiler author might want to save their users some grief by eliminating deleted functions earlier, on the grounds that you can't call a deleted function, so why bother including it in the overload set?
Related
From http://eel.is/c++draft/class.member.lookup#1 :
A search in a scope X for a name N from a program point P is a single search in X for N from P unless X is the scope of a class or class template T, in which case the following steps define the result of the search.
[Note 1: The result differs only if N is a conversion-function-id or if the single search would find nothing. — end note]
I'm having a hard time making a sense of the Note. It seems that a "single search" from a class scope will find preceding declarations at namespace scope, since the namespace scope contains the class scope. But, as we know, if the name has also been declared as a member of a non-dependent base class, then the base class member takes precedence over the namespace member. Note 1 seems to contradict this, since it's basically saying "if N is not a conversion-function-id, then you can just do a normal single search, and only if you fail to find anything, then use the procedure in this section". But the single search will succeed by finding the namespace scope declaration, and the class member lookup will yield a different result.
Where is the error in my understanding?
Answer
A single search considers only one scope—not an enclosing namespace or even a base class. It’s an unqualified search that considers all enclosing scopes. Single searches and (plain) searches are subroutines of these higher-level procedures.
Context
It should be said, since there have been a lot of these questions lately, that these terms exist to reduce ambiguity and imprecision (e.g., CWG issue 191) in the definitions of “programmer-level” constructs like (un)qualified name lookup. I didn’t invent them to increase the number of vocabulary words that the typical programmer should be expected to have memorized. (Put differently, the standard is not a tutorial.)
Of course, there’s nothing special about this particular question in this regard, but I must hope that this will thereby tend to find the people that need to see it.
The purpose of a "single search" is used to state how the lookup should perform for the member. In simple, if a single search is used to find the member in the namespace's scope, its enclosing scope will not be continue found due to the single search here, if there is no declaration yet found.
As the rule you quoted here, the scope of the class or class template is an exception here to the "single search", which means the single search should continue to be performed in its base classes if nothing yet found.
The declaration set is the result of a single search in the scope of C for N from immediately after the class-specifier of C if P is in a complete-class context of C or from P otherwise.
This is a recursive procedure. Hence, the note says "The result differs only if the single search would find nothing."
Whereas for "The result differs only if N is a conversion-function-id" because of the following rule:
In each case where conversion functions of a class S are considered for initializing an object or reference of type T, the candidate functions include the result of a search for the conversion-function-id operator T in S.
It does not mean the name "operator T" is the unique name to be lookup for the conversion function, the "permissible types" are also candidates to be found according to the relevant rule.
Each such case also defines sets of permissible types for explicit and non-explicit conversion functions;
Anyway, the note is used to say the exception for a "single search" which shouldn't have found any declaration by the single search but the other candidate ways would find them.
In C++, is there a difference between name binding and name lookup in? The working draft C++14 standard (N4296) defines name lookup in (3.4) as
Name lookup associates the use of a name with a declaration (3.1) of that name.
I can't find a definition for name binding in the standard, but the IBM Knowledge Center documentation for their XL C/C++ compiler defines:
Name binding is the process of finding the declaration for each name that is explicitly or implicitly used in a template.
The only distinctions between the two definitions seem to be that (1) name binding refers specifically to a name used in a template and (2) name binding refers to a name, while name lookup refers to the use of a name.
However, Section (13.3) on Overload Resolution in the C++ standard mentions binding frequently, but without defining it. The way 'binding' is used in this context makes it seem that binding refers to the association of an argument with a function parameter.
At first, this definition seems different from either of the other two definitions, thought it fits (broadly) the definition of name lookup if we assume that the name of the function is being bound to its declaration by comparing the types of arguments and parameters. That isn't exactly the sense used in Section (13.3), but I'm trying to make sense of the standard without a proper definition.
In short, if anyone has a good definition of 'name binding' or 'binding', I'd be grateful.
Having read the relevant parts of Wilson & Clark Comparative Programming Languages, I think I have a better understanding of the topic. If I surmise correctly, the term 'binding' covers a gamut of related terms, including name-declaration binding, name–type binding, declaration-reference binding, reference-value binding, and name-value binding.
"Name lookup" seems to be a synonym for name-declaration binding. The other uses of 'binding' in the C++14 standard relate to various combinations of the other varieties of binding.
Please correct me if I'm wrong!
In C++ 5.1.1/3 [expr.prim.general] it says:
The type and value category [of this] are defined within a static member function.
What does this mean? How is it relevant?
Note that:
this shall not appear in the declaration of a static member function
The language in the standard can be traced to n3282, which is a resolution for defects 1207 and 1017. In particular, the language appears in the proposed resolution for defect 1207, and thus should be considered in the context of the standard as it stood at the time that defect was addressed. At that time there was some concern over the rewriting of id-expressions into member access expressions using *this (9.3.1p3), in particular in the context of trailing-return-type declarations (see issue 945).
If we compare the proposed resolution to defect 1207 to the eventual language in n3282 and subsequently in the standard, there is one significant difference to 9.3.1p3:
Defect 1207:
When an id-expression (5.1 [expr.prim]) that is not part of a class member access syntax (5.2.5 [expr.ref]) and not used to form a pointer to member (5.3.1 [expr.unary.op]) is used in the declaration of a member function of class X, if name lookup (3.4 [basic.lookup]) resolves the name...
n3282 and C++11:
When an id-expression (5.1 [expr.prim]) that is not part of a class member access syntax (5.2.5 [expr.ref]) and not used to form a pointer to member (5.3.1 [expr.unary.op]) is used in a member of class X in a context where this can be used (5.1.1 [expr.prim.general]), if name lookup (3.4 [basic.lookup]) resolves the name [...]
It is apparent that the proposed resolution to defect 1207 carried the belief that id-expressions (to a static member) within a static member functions would need to be transformed to *this member access expressions and thus would need access to the type and value category of this. By the time n3282 was written this had been resolved in favour of the qualified-id transformation (also 9.3.1p3) which does not require this, but the language in 5.1.1p3 remained vestigially.
I would recommend raising this issue on the C++ standards discussion newsgroup; it may be possible to get the vestigial language removed editorially.
For unqualified name lookup, 'Usual unqualified lookup' and 'Argument-dependent name lookup'(ADL), I cannot find in standard which one happens first ?
Again as both trying to add something to the overload candidate set, the order doesn't seems to be matter though. But would still be nice to know which one happens first.
Thanks
It doesn't matter which comes first, does it? Name lookup generates a set of possible names.
3.4 Name lookup
Name lookup may associate more than one declaration with a name if it finds the name to be a function name; the declarations are said to form a set of overloaded functions.
The standard specifically says "set". As a mathematical construct, the set {1,2,3} is the same as {2,3,1} and {3,2,1}. Order doesn't matter. What does matter is when overload resolution and the application access rules occurs. Here the standard is very clear. Quoting once again from the intro paragraph to 3.4:
Overload resolution takes place after name lookup has succeeded. The access rules are considered only once name lookup and function overload resolution have succeeded.
Where I can find a list of the rules that a C++ compliant compiler must apply in order to perform names resolution (including overloading)?
I'd like something like a natural-language algorithm or flow chart.
C++ standard of course has this set of rules but it is build up as new language statements are introduced and the result it's pretty hard to remember.
To make a long story short, I'd like to know the complete and detailed answer to the question "What compiler do when it see the name 'A'?"
I know C++ is all "We do this when X but not Y if Z holds" so, I'm asking whether it is possible to make it more linear.
EDIT: I'm working on a draft of this topic, something that may be improved collectively once posted. However i'm very busy this days and it may take time to have something publicable. If someone interested i'll promote the "personal note on a raw txt file" to something better and post it.
Well, in broad strokes:
If the name is preceded by ::, as in ::A or X::A, then use qualified name lookup. First look up X, if it exists (if not use the global namespace) then look inside it for A. If X is a class, and A is not a direct member, then look in all the direct bases of X. If A is found in more than one base, fail.
Otherwise, if the name is used as a function call such as A( X ), use argument-dependent lookup. This is the hard part. Look for A in the namespace the type of X was declared in, in the friends of X, and if X is a template instantiation, likewise for all the arguments involved. Scopes associated only by typedef do not apply. Do this in addition to unqualified lookup.
Start with unqualified lookup if argument-dependent lookup doesn't apply. This is the usual way variables are found. Start at the current scope and work outwards until the name is found. Note that this respects using namespace directives, which the other two cases do not.
Simply glancing at the Standard will reveal many exceptions and gotchas. For example, unqualified lookup is used to determine whether the name is used as a function call, as opposed to a cast-expression, before ADL is used to generate a list of potential overloads. Unqualified lookup doesn't look for objects in enclosing scopes of nested of local classes, because such objects might not exist at the time of reference.
Apply common sense, and ask more specific questions when (as often it does) intuition fails.