daniel@cis.ucsc.edu (Daniel Edelson) (09/17/90)
Section 9.1 of the AT&T C++ Language System Release 2.1
Product Reference Manual (select code 307-159)
says: ``If a class mentioned as a friend has not been declared
its name is entered into the same scope as the name of the class
containing the friend declaration.''
This means that the semantics of a name declared as a friend
differ for classes and functions.
For example:
class outer {
class inner {
private:
friend class cl; /* cl is a friend class */
friend void fu(); /* fu is a friend function */
};
class cl { }; /* this IS a friend class */
void fu() { } /* this is NOT a friend function */
};
class cl { }; /* this is NOT a friend class */
void fu() { } /* this IS a friend function */
Presumably this distintion became necessary with the introduction
of local and nested classes, there are no local functions or functions
nested in functions, and functions nested in classes have special
meaning.
The above scenario is how I interpret the rules as outlined in the ARM.
It would be possible to define the ``friend void fu()'' declaration
from the above example as declaring that outer::fu() is a friend
of inner. This actually seems consistent and natural, however it falls
apart when inner is a local class.
I suggest that the rule be changed back to:
``If a class mentioned as a friend has not been
declared its name is entered into the global scope.''
This is consistent and easy to program with.
There are not special rules setting apart functions and classes.
The current behavior is trivial to obtain as well:
class outer {
class cl;
class inner {
friend class cl;
};
};
If this definition is not adopted then it should be legal to say:
class outer {
class inner {
friend class ::cl;
};
class cl {}; /* Not a friend */
};
class cl { }; /* Yes a friend */
to explicitly declare the global class to be the friend.
Daniel Edelson | ADA --> B1 bomber
daniel@cis.ucsc.edu, or | C --> F15E fighter
...!sun!practic!peren!daniel | C++ --> Space shuttle