bill@gibbons.org (Bill Gibbons) wrote:

>....
>Instead, the working paper now (if it were clear) specifies that friends
>are added "invisibly" to the enclosing namespace, and are not normally
>found by name lookup unless they are also declared in the normal manner.
>During name-dependent lookup, friends of classes associated with the
>argument types become visible for purposes of name lookup.
>...

Thanks for explaining the new friend rules. I suspected the intent was
as you described. This seems to be a very nice solution to a lot of
problems, including the issue Esa Pulkkinen raised in the original
thread of relying on the ODR to avoid ambiguous instantiations- those
cases should now become compile-time detected ambiguous lookup errors.

In fact, inline friend definitions are now more like static member
functions with  (non-virtual) member function-like lookup;  which
would seem to make them a lot more flexible.

,Brian Parker (bparker@gil.com.au)
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]

In article <5g239j$14j11@gilnt2.ipswich.gil.com.au>, bparker@gil.com.au
(Brian Parker) wrote:

> Actually, I found the Dec 96 draft confusing on the issue of friends.
> I am not sure if the kind of code used in Barton & Nackman is still
> draft-conforming. Sec 14.6.5 [temp.inject] says that friend functions
> do not introduce any new names into any scope & then gives an example
> of name-dependent lookup looking inside a class to find a friend
> definition. I am not clear on how that is supposed to work; I thought
> name-dependent lookup started in the namespace surrounding a class,
> not in the class itself (at least not for a non-member).

The Dec 96 working paper is indeed unclear on this, and X3J16/WG21 has
noted that this needs to be clarified.

There is no longer any "name injection" for friends of class templates.
The problem was that injection was supposed to occur at the "point of
instantiation".  But since injection affects name lookup, which in
turn affects parsing, which in turn affects whether a template should
be instantiated, there is no simple way to formulate the rules.  Of
course there are non-simple ways to formulate the rules, such as adding
another "reconsideration rule".

(Without complex rules, making injection well-defined would require that
it occur too late to be useful.)

But since there are other reasons why instantiation should not have any
compile-time side-effects, the choice was made to eliminate this kind
of name injection.

Instead, the working paper now (if it were clear) specifies that friends
are added "invisibly" to the enclosing namespace, and are not normally
found by name lookup unless they are also declared in the normal manner.
During name-dependent lookup, friends of classes associated with the
argument types become visible for purposes of name lookup.

This eliminates name injection from instantiation, while preserving not
only common uses of friends but also many less obvious techniques
such as those in Barton & Nackman.

Of course there are rare cases which no longer work, such as when the
friend does not depend on the class in any way or when an injected name
used to hide a type name in an outer namespace.  Almost all of these
cases can be handled by explicitly declaring the friend as a
namespace-scope template function, which is a much clearing coding
style anyway.  And it also works with both older and newer compilers.


-- Bill Gibbons

--
Bill Gibbons
bill@gibbons.org
---
[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]