Pourquoi c++ ne permet pas l'amitié héréditaire?

pourquoi l'amitié n'est-elle pas au moins optionnellement héréditaire en C++?

je pense que la réponse à votre première question Est dans cette question: " est-ce que les amis de votre père ont accès à vos parties intimes?"

une classe amie peut exposer son ami à travers les fonctions d'accesseur, puis accorder l'accès à travers ceux-ci.

class stingy {
    int pennies;
    friend class hot_girl;
};

class hot_girl {
public:
    stingy *bf;

    int &get_cash( stingy &x = *bf ) { return x.pennies; }
};

class moocher {
public: // moocher can access stingy's pennies despite not being a friend
    int &get_cash( hot_girl &x ) { return x.get_cash(); }
};

cela permet un contrôle plus fin que la transitivité optionnelle. Par exemple, get_cash peut être protected ou peut appliquer un protocole d'accès limité à l'exécution.

C++ Standard, section 11.4 /8

l'Amitié n'est ni héréditaire, ni transitive.

si l'amitié était héréditaire, alors une classe qui n'était pas censée être une amie aurait soudainement accès à votre intérieur de classe et qui viole l'encapsulation.

parce que c'est inutile.

l'utilisation du mot-clé friend est elle-même suspecte. En terme de couplage, c'est la pire relation (loin devant l'héritage et la composition).

Tout changement à l'intérieur d'une classe ont un risque d'impact les amis de cette classe... voulez-vous vraiment un nombre inconnu d'amis ? Vous ne seriez même pas en mesure de les énumérer si ceux qui héritent d'eux peuvent aussi être des amis, et vous courrait dans le risque de briser le code de vos clients à chaque fois, sûrement ce n'est pas souhaitable.

j'admets librement que pour les devoirs/projets de compagnie la dépendance est souvent une considération lointaine. Sur les petits projets, ça n'a pas d'importance. Mais dès que plusieurs personnes travaillent sur le même projet et de ce qui pousse dans les dizaines de milliers de lignes, vous devez limiter l'impact des modifications.

cela apporte une règle très simple:

Modifier les internes d'une classe ne devrait affecter la classe elle-même

bien sûr, vous affecterez probablement ses amis, mais il y a deux cas ici:

• fonction libre d'ami: probablement plus d'une fonction de membre de toute façon (je pense std::ostream& operator<<(...) ici, qui n'est pas un membre purement par accident des règles de langue
• classe des amis ? tu n'as pas besoin de cours sur les vrais cours.

je recommande l'utilisation de la méthode simple:

class Example;

class ExampleKey { friend class Example; ExampleKey(); };

class Restricted
{
public:
  void forExampleOnly(int,int,ExampleKey const&);
};

Ce modèle simple Key vous permet de déclarer un ami (d'une certaine manière) sans lui donner réellement accès à vos internes, l'isolant ainsi des changements. En outre, il permet à cet ami de prêter sa clé aux administrateurs (comme les enfants) si nécessaire.

une supposition: si une classe déclare une autre classe/fonction en tant qu'ami, c'est parce que cette deuxième entité a besoin d'un accès privilégié à la première. À quoi sert-il d'accorder à la seconde entité un accès privilégié à un nombre arbitraire de classes dérivées de la première?

une classe dérivée ne peut hériter que de quelque chose, qui est "membre" de la base. Une déclaration d'ami est pas un membre de la classe amie.

$11.4/1- "...Le nom d'un ami est pas dans le champ d'application de la classe, et la ami n'est pas appelé avec le membre des opérateurs d'accès (5.2.5) sauf s'il est un membre d'une autre classe."

$ 11.4 - " aussi, parce que le la base de la clause de la classe amie ne fait pas partie de son déclarations des membres, clause de base de la classe ami ne peut pas accéder à noms des personnes privées et protégées membres de la classe accordant amitié."

et plus loin

$10.3/7- "[Note: le spécificateur virtuel implique l'adhésion, de sorte que virtuel fonction ne peut être un tiers (7.1.2) fonction. Ni une fonction virtuelle être un membre statique, depuis un virtuel l'appel de fonction repose sur un objet pour déterminer quelle fonction invoquer. Une fonction virtuelle déclarée dans une classe peut être déclaré un ami dans une autre classe. ] "

Depuis le " ami " n'est pas un membre de la classe de base, en premier lieu, comment peut-il être héritée par la classe dérivée?

Ami de la fonction dans une classe attribue la extern propriété de la fonction. c'est-à-dire qu'externe signifie que la fonction a été déclarée et définie quelque part en dehors de la classe.

cela signifie donc que la fonction d'ami n'est pas un membre d'une classe. Donc, l'héritage permet d'hériter des propriétés d'une classe pas les choses extérieures. Et aussi si l'héritage est autorisé pour les fonctions d'ami, alors une classe de tiers héritant.

ami est bon dans l'héritage comme l'interface de style pour conteneur Mais pour moi, comme le premier dire, C++ manque l'héritage propageable

class Thing;

//an interface for Thing container's
struct IThing {
   friend Thing;
   protected:
       int IThing_getData() = 0;
};

//container for thing's
struct MyContainer : public IThing {
    protected: //here is reserved access to Thing
         int IThing_getData() override {...}
};

struct Thing {
    void setYourContainer(IThing* aContainerOfThings) {
        //access to unique function in protected area 
        aContainerOfThings->IThing_getData(); //authorized access
    }
};

struct ChildThing : public Thing {
    void doTest() {
        //here the lack of granularity, you cannot access to the container.
        //to use the container, you must implement all 
        //function in the Thing class
        aContainerOfThings->IThing_getData(); //forbidden access
    }
};

Pour moi, le problème de C++ est le manque de très bonne granularité contrôler tous les accès de n'importe où pour n'importe quoi:

le truc de l'ami peut devenir le truc de l'ami.* accorder l'accès à tout enfant D'une chose

et plus, ami [région nommée] chose.* pour accorder un accès précis sont dans la classe de Conteneur dans le domaine de l'ami.

Ok arrêter le rêve. Mais maintenant, vous connaissez un usage intéressant d'ami.

dans un autre ordre, vous pouvez également trouver intéressant de savoir toutes les classes sont amicaux avec soi-même. En d'autres termes, une instance de classe peut appeler tous

membres d'une autre instance du même nom sans restriction:

class Object {
     private:
         void test() {}
     protected:
         void callAnotherTest(Object* anotherObject) {
             //private, but yes you can call test() from 
             //another object instance
             anotherObject)->test(); 
         }
};