Geek Answers Handbook

C ++ Friendship and Inheritance

I know that friendship is not inherited. I asked myself: why? Why did C ++ designers decide not to inherit friendship? Do you find inheritance of friendship would be beneficial? My own answer is yes: just as B is a friend of A, I would like the whole family of classes to be a friend of A (B and its derivatives). Maybe we can say: let only B be a friend of A or let B and its derived classes be friends of A.

Ps. I do not know why many of you thought that I would ask for an automatic extension of friendship. I was more interested in the opportunity for the programmer to expand friendships for the whole family, using some mechanism (not automatically).

+4
source share
3 answers

The A friend ad creates a strong relationship between friend and trust:

  • he associates Friendly with the Trusting view as he has gained full access to its internal functions.
  • this means that Friendly agrees to support Trusting class invariants

Therefore, it seems good practice to clearly define the exact scope of what inheritance failed to achieve: a leak has occurred.

True, true that inheritance is not even necessary. There are actually two alternatives, depending on what kind of friendship you are trying to achieve. They cover any scenario that I have ever encountered.

Proxy friendly

In your example, derivatives from Friendly can simply go to Trusting through Friendly , which allows you to manage operations that occur on Trusting in a limited set of locations.

 class Trusting { friend class Friendly; }; class Friendly { protected: void modifyTrusting(); };

A modifyTrusting implementation may mean virtual calls (hooks) to customize the behavior, but regardless of these bindings, it is up to Friendly to ensure that class invariants are not broken.

Not so trust

In this case, Trusting opens only part of its interface through a locked method and provides a key for Friendly . Friendly can alternatively provide a key to classes in which it trusts, but this does not really matter ... In any case, Trusting ensures that its invariants are not violated, and the key is just a mechanism to reduce the impact of the method.

 class Key { friend class Friendly; Key() {} ~Key() {} }; class Trusting { public: void doSomething(Key const&); }; class Friendly { protected: Key const& key() const; };

I must admit that I am really part of this last method and use it regularly because it limits the exposure of Friendly details of the implementation of Trusting . It also clearly documents which parts of Trusting our expensive access are Friendly .

+4
source

Yesterday I saw a funny bumper sticker: "My mother-in-law is a travel agent ... to commit guilt." Friendship is inherited to some extent in human relationships. Although this leads to interesting jokes about friends and the SO family, it is important to remember that suffering and suffering are the basis for many jokes.

Friendship is not inherited in C ++, because the developers foresaw the amount of suffering and suffering that this could cause.

+2
source

This is a terrible idea.

Friendship is not inherited, because friendship causes a close relationship between friends. If all the derived classes were also automatically friends, this would create a tight binding between the source object and all the inherited classes.

A tight connection is good for classes that are created and maintained together. But for classes created by other users, a tight connection will lead to a maintenance nightmare and will not allow you to ever change the original object (because all your closely related friends depend on your implementation).

+1
source

More articles:


All Articles