🚀 go-pugleaf

In article 41C67EA6@mccabe.com, "Craig P. Forbes" <craig@mccabe.com> writes:

>When a friend is declared within a class (or sub class) at what
>scope is the friend defined to be in.
>Is it the enclosing scope or global scope?

>i.e.

>class c1 {
>   class c2 {
>      friend class b;
>      friend int fn();
>   };
>};

>In what scope are b and fn().

If the function or class name declared in a friend declaration has not been
previously declared, that name is introduced into the smallest enclosing
non-class, non-function-prototype scope. In this example, assuming no
prior declaration of b or fn, they are declared in file scope.

Reference: 3.3.1, Point of Declaration. (September draft)

Details of this kind of "name injection" were not well-defined by the ARM,
and took considerable discussion in the C++ committee to resolve. I would
not be surprised to see different results from current compilers.

Your safest course is to have a visible file-scope declaration for b and fn.
Assuming the names are not hidden, all compilers should then treat the
friend declarations as referring to those existing declarations.

If you mean for b or fn to refer to something local to c1 or c2, you
must insert some extra declarations in the proper scope.

>On a related note I will reiterate a question I resently saw but
>have not seen an answer.
>Can friends be defined within the friend class?
>
>i.e. Is this legal?
>class c1 {
>   friend class fc { ... };
>};

I believe the rule in 3.3.1 applies to this case, and that the 
definition of fc is allowed and is put in file scope. I don't know
what current compilers will do with this example.

In any event, I always recommend against defining friends inside classes.
Just declare them as friends in the class, and define the class or function
in its proper scope. It is less confusing for human readers that way, and
you don't have to wonder what the compiler will do.

---
Steve Clamage, stephen.clamage@eng.sun.com




---
[ comp.std.c++ is moderated.  Submission address: std-c++@ncar.ucar.edu.
  Contact address: std-c++-request@ncar.ucar.edu.  The moderation policy
  is summarized in http://dogbert.lbl.gov/~matt/std-c++/policy.html. ]