Boost logo

Boost :

From: David Abrahams (abrahams_at_[hidden])
Date: 2001-05-20 17:51:41

----- Original Message -----
From: "John Max Skaller" <skaller_at_[hidden]>

> rwgk_at_[hidden] wrote:
> > Would this be a valid summary:
> > - A fully conforming compiler will find the friend functions
> > through Koenig lookup, and only through Koenig lookup.
> Perhaps I'm missing something, but anyhow ..
> The role of 'friend' functions has changed since ARM days.
> It used to be you could 'declare' and even define a friend
> function inside a class.

You still can.

> But then, there was a problem
> that to find it from outside the class, it needed to
> be 'injected' into the scope outside the class.
> This 'friend injection' turned out to cause all sorts
> of problems (especially with templates involved as well).
> So friend functions _first declared in a class_ are no
> longer injected outside the class.
> The solution is: ALWAYS declare the function first,
> outside the class. Like this:
> void f();
> class X { friend void f(); };
> void f() { .. }
> The friend declaration does nothing here except
> let the definition of f get at the private parts of X:
> it has no impact on lookup, it is refering to an already
> declared function. The function f() is defined after the
> class definition to get at the private part of the class.
> More simply: do NOT use friend declarations to declare
> anything. Just use them to grant friendship.

I don't accept either rule. The Barton & Nackmann trick used by the
operators libraries depends on violating it. I also need to violate it in
the Python library.
There's nothing wrong with using friend declarations to declare/define a
function, as long as you're prepared for the function to be found only using
argument dependent lookup.


Boost list run by bdawes at, gregod at, cpdaniel at, john at