Re: ISO/IEC 14882 =?ISO-8859-1?Q?=A73.3?= friend, extern and scope
Richard Corden wrote:
Steven T. Hatton wrote:
[...]
Please let me try to get one point clarified before I address your reply.
This is from TC++PL(SE) ?11.5.1:
<quote>
Like a member declaration, a friend declaration *does* *not* *introduce*
*a* *name* into an enclosing scope. For example:
class Matrix{
friend class Xform;
friend Matrix invert(const Matrix&);
};
Xform x; //error: no Xform in scope
Matrix(*p) (const Matrix&)= &invert; //error: no invert() in scope
</quote>
These are from the Standard:
?3.3 #4" ... friend declarations (11.4) *may* *introduce* *a* (possibly
not visible) *name* into an enclosing namespace;.."
?3.3.1 #6"friend declarations refer to functions or classes that are
members of the nearest enclosing namespace, but *they* *do* *not*
*introduce* *new* *names* into that namespace."
Which of the above statements is applicable to Stroustrup's example? Can
you provide an example of where the statement not applicable to the above
example is applicable?
Firstly, the section quoted from 3.3#4, and also 3.3.1#6 are notes. It
is therefore important to consider them only in connection with the
normative words under 7.3.1.2#3
I don't have any reason to understand notes to be non-normative in the
context of the Standard. I believe there are some cases where a feature of
the language is specified entirely in a footnote. In the particular cases
under discussion, it may be possible to glean the actual intent of the
author of the note by examining the referenced sub-clause, but I will still
contend that the wording is inadequate. It could and should be clearer.
In 3.3#4, the first part of the sentence included elaborated types which
*do* add names into the enclosing namespace. My impression would be
that "(possibly not visible)" was added to the note so the paragraph
didn't cause confusion with 7.3.1.2. The same more or less applies to
3.3.1#6.
TBH, I don't actually see any conflict with the TC++PL example and the
words of the standard. Neither 'Xform' nor 'invert' are "visible" in
the enclosing namespace. Therefore the type used in the definition of
'x' cannot be found, and neither can the initialiser to the definition
of the function pointer 'p' (ADL only occurs where the postfix
expression of a function call is an unqualified non template-id);
I can honestly rearrange and abridge the wording to expose the following
meanings from the two statements in question:
"friend declarations *do* *not* *introduce* *new* *names* into that
enclosing namespace."
"friend declarations *may* *introduce* *a* *name* into an enclosing
namespace;"
Those two statements are mutually contradictory.
throw std::logic_error("0==1");
I have to say that I am confused about the sentence in ?7.3.1.2/3 "If a
friend function is called, its name may be found by the name lookup
that considers functions from namespaces and classes associated with
the types
of the function arguments (3.4.2)." Taken out of context I would not
question what it means. But given the subsequent sentence, it is not
clear to me if I should understand it to be placing a restriction on
the one
quoted above. IOW, will ADL find the definition of a function in
another namespace if the function name is not explicitly qualified?
Ok - The two sentences are unrelated.
I contend that the wording of the paragraph is inadequate.
The one thing I've found with the standard is that once I get to
understand a paragraph, it becomes verify difficult to see a better way
to word it that doesn't add in it's own new issues. However, getting to
understand the standard is the problem!
I've done OK with several of the Upanishads, The Bhagavad-Gita. The Tao Te
Ching, The Dhammapada, The H?vam?l, The V?lusp?, etc. I know there are
people who treat C++ as a religion, but I am not willing to accept that a
programming language specification should require the methodology of
ancient and arcane theological scripture. Furthermore, proper translations
of any of the above mentioned texts will not contain overt logical
contradictions.
I believe you probably grasp the intent of the authors of the Standard. I
am not ungrateful for your help in my effort to do the same. I do not
claim that I could write a better language specification. I do, however,
make my share of errors, so I know what they look like, and the above
exposed contradiction looks exactly like an error to me.
I will continue to read the Standard document with the assumption that the
intended meaning will become clear in the sequel.
--
Regards,
Steven
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]