Re: need for friend function

From:

"Victor Bazarov" <v.Abazarov@comAcast.net>

Newsgroups:

comp.lang.c++

Date:

Tue, 4 Dec 2007 16:04:59 -0500

Message-ID:

<fj4fdt$c5r$1@news.datemas.de>

robertwessel2@yahoo.com wrote:

[..]
My complaint about friendship is that its too coarse grained. I
almost never see the situation where one class actually needs to
access the private data members of another (and that's usually pretty
easy to design around, even if you just add some getters and
setters). What I have run into is the situation where two or more
classes need to share some interfaces within the group, but not with
classes outside that group.

While there are ways around that (notably making the semi-public
interfaces part of derived classes, although that brings other
problems, particularly the need to use a factory method), none of the
workarounds are all that clean (of course, neither is excessively
permissive friendship).

To provide the functionality where only members of the group have
access to each other's privates ("family"? :-)) you can define
a "shared" class which will be the friend of them all and though
which they will request the access. Kind of like this:

    class A {
        int a;
        friend class P;
    public:
        void foo();
    };

    class B {
        int b;
        friend class P;
    public:
        void foo();
    };

    class P { // everything is private
        friend class A;
        friend class B;
        static int &a(A& ai) { return ai.a; }
        static int &b(B& bi) { return bi.b; }
    };

    void A::foo() {
        B myb;
        a = P::b(myb);
    }

    void B::foo() {
        A mya;
        b = P::a(mya);
    }

    int main() {
        A a;
        B b;
        a.foo();
        b.foo();
    }

Note that 'A' is not a friend of 'B', nor 'B' is a friend of 'A'.

V
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask