C++: Pourquoi faut-il privé des fonctions-ils être déclarés?

Pourquoi les classes en C++ doivent déclarer leurs fonctions privées? Elle a de réelles raisons techniques (quel est son rôle au moment de la compilation) ou est-ce simplement pour des raisons de cohérence?

  • Demandez-vous pourquoi les fonctions elles-mêmes doivent être déclarés, ou demandez-vous pourquoi vous avez à dire private pour ces fonctions?
  • Je pense que la première.
  • 1er. Je ne sais pas pourquoi les autres classes, y compris l'en-tête doivent savoir au sujet de ses fonctions privées
  • ils n'en ont pas. C'est l'info pour la classe elle-même - c'est à dire la classe sait que foo est membre et a accès à d'autres membres.
  • private et virtual sont orthogonaux concepts. Le fait qu'une fonction est private n'implique pas qu'il n'est pas virtual (comme une question de fait, il y a tout un idiome d'avoir seulement private virtual et public non virtuelle fonctions de membre), donc oui, la présence d'affecter la vtable.
  • bon point. En fait je ne savais pas privé virtuel de fonctions peut être redéfinie dans les classes enfant et ont leurs classes de base d'appel de la nouvelle version sans exposer callability(est-ce encore un mot?)
  • Le mot que vous voulez, c'est "l'accessibilité".

InformationsquelleAutor Ancurio | 2012-07-17
  1. 21

    J'ai demandé pourquoi les fonctions privées dû être déclarée, comme ils ne pas ajouter quoi que ce soit (ni la taille de l'objet, ni la vtable entrée) pour d'autres unités de traduction à savoir

    Si vous pensez à ce sujet, ce qui est similaire à la déclaration de certaines fonctions static dans un fichier. Il n'est pas visible de l'extérieur, mais il est important que le compilateur lui-même. Le compilateur veut savoir la signature de la fonction avant de l'utiliser. C'est pourquoi vous déclarer des fonctions en premier lieu. Rappelez-vous que les compilateurs C++ sont un seul passage, ce qui signifie que tout doit être déclaré avant d'être utilisé.1

    À partir du programmeur point de vue, en déclarant privé des fonctions n'est pas encore complètement inutile. Imaginez 2 classes, dont l'une est la friend de l'autre. Le friendzoned classe2 aurait besoin de savoir comment les soldats de la classe ressembler, (Cette discussion est d'obtenir bizarre) sinon ils ne peuvent pas l'utiliser.

    Pourquoi exactement C++ a été conçu de cette façon, je voudrais tout d'abord dire qu'il y a de la raison historique: le fait que vous ne pouvez pas couper un struct en C, a été adopté par le C++, donc vous ne pouvez pas couper une classe (et adoptée par d'autres langues ramifié en C++, trop). J'avais aussi pense que c'est le sujet de la simplicité: Imaginez combien il serait difficile de concevoir une méthode de compilation dans laquelle vous pouvez diviser la classe parmi les différents fichiers d'en-tête, laissez vos fichiers source du savoir, et d'empêcher les autres d'ajouter des choses à votre classe.

    Une dernière remarque est que, private fonctions peut affecter la vtable de taille. C'est, si elles sont virtual.

    1 en Fait, pas tout à fait. Si vous avez des fonctions inline dans la classe, ils peuvent se référer à des fonctions plus tard définies dans la même classe. Mais probablement que l'idée a commencé à partir d'une seule passe et cette exception a ajouté plus tard pour elle.

    2 C'est inline fonctions de membre en particulier.

    • Ouais, j'ai l'habitude de cacher l'implémentation en C en utilisant statique fonctions C, c'est pourquoi j'aurais attendu de simplement déclarer, avant toute mise en œuvre) des fonctions privées à l'intérieur de la rpc à l'écart du reste, tout comme statique déclarations en C
    • L ' "ami" de cas d'utilisation, cependant, est un argument valable. Merci.
    • même si ce que vous dites absolument de sens, il n'existe malheureusement pas de support de C++ pour couper une définition de la classe en deux.
    • Avoir les signatures déclaré avant d'en faire usage n'est que vaguement liés à la raison d'être dans la classe elle-même. Le friendzoned classe n'a pas besoin de connaître les soldats de l'autre, il est membre des définitions de fonction ont besoin de savoir les simples soldats. Cela peut aussi venir plus tard ou en dehors de la classe. Et il y a des choses intéressantes que vous pouvez faire avec des modèles de ce qui pourrait être dit pour couper une définition de la classe en deux. Ce qui me rappelle les définitions de classe avec les fonctions inline est deux passes, pas un seul passage. C'est pourquoi vous pouvez utiliser les membres ou fonctions à un membre de la définition de la fonction avant ce membre est déclaré.
    • en effet, je suis conscient que le passage sur la déclaration de la classe elle-même n'est pas un passage. Toutefois, cela s'applique puisque la plupart du temps, vous définissez les fonctions en dehors de la classe, après la classe a été déclaré. Comme je l'ai dit dans un commentaire ci-dessus, il aurait été agréable si vous pouviez mettre les déclarations de membres privés/fonctions internes fichier d'en-tête, mais il n'y a pas de support direct pour elle. (Vous pouvez toujours avoir une void *internal;, mais c'est juste une solution de contournement).
    • Ainsi, comme l'OP demandé, pourquoi il n'y a pas de support pour elle?
    • outre les raisons historiques (le fait que vous ne pouvez pas couper les struct en C, a été adopté par le C++, donc vous ne pouvez pas couper les class (et adoptée par d'autres langues ramifié en C++, trop), je suppose que c'est à propos de la simplicité. Imaginez combien il serait difficile de concevoir un plan de sorte que vous pouvez diviser la classe parmi les différents fichiers d'en-tête, que tout le monde sache à ce sujet, et d'empêcher les autres d'ajouter des choses à votre classe.

    InformationsquelleAutor Shahbaz
  2. 20

    Vous devez déclarer tous les membres dans la définition de la classe elle-même, de sorte que le compilateur sait quelles fonctions sont permis à être membres. Sinon, un second programmeur pourrait (accidentellement?) venez et ajouter des membres, de faire des erreurs, et de violer l'objet de garanties, provoquant un comportement indéfini et/ou des plantages aléatoires.

    • Je pense que vous venez de décrire les classes Python =)
    InformationsquelleAutor Mooing Duck
  3. 3

    Il y a une combinaison de préoccupations, mais:

    • C++ ne permet pas de ré-ouvrir une classe de déclarer de nouveaux membres dans après sa définition initiale.
    • C++ ne permet pas d'avoir des définitions différentes d'une classe dans les différentes unités de traduction qui se combinent pour former un programme.

    Donc:

    • Privé des fonctions membres qui le .fichier cpp veut déclarée dans la classe doivent être définies dans le .h fichier, chaque utilisateur de la classe voit trop.

    De la POV de pratique de la compatibilité binaire: comme David dit dans un commentaire, privé virtual fonctions affectent la taille et la disposition de la vtable de cette classe et de toutes les classes qui l'utilisent comme base. Ainsi, le compilateur a besoin de les connaître, même lors de la compilation de code qui ne peut pas les appeler.

    Pourrait C++ ont été inventé différemment, pour permettre à l' .fichier cpp de rouvrir la classe et les ajouter certains types de membres supplémentaires fonctions, avec la mise en œuvre doivent veiller à ne pas rompre la compatibilité binaire? Pourrait une définition de la règle est assouplie, afin de permettre des définitions qui diffèrent à certains égards? Par exemple, les fonctions membres statiques et non virtuelle non-fonctions membres statiques.

    Probablement oui pour les deux. Je ne pense pas qu'il n'y a aucun obstacle technique, bien que l'ODR est très strict sur ce qui rend une définition de "différent" (et par conséquent est très généreux pour les implémentations permettant binaire incompatibilités entre très similaire à la recherche de définitions). Je pense que le texte à introduire ce genre d'exception à la règle serait complexe.

    En fin de compte, il pourrait en venir à la, "les concepteurs ont voulu de cette façon", ou il pourrait être que quelqu'un l'a essayé et a rencontré un obstacle que je n'ai pas pensé.

    • Les modules actuels propositions ont des solutions à la question de la vie privée, tout simplement parce qu'ils ajoutent une autre "couche" ou "pièce" de la visibilité: La classe elle-même, le module, le "outer code". private sera alors tout simplement pas de fuite en dehors de la définition de module, et le compilateur ne peut pas toujours tout savoir.
    • "C++ ne permet pas de ré-ouvrir une classe de déclarer de nouveaux membres dans après sa définition initiale." Qui n'est pas correct: l'article 14.7.3 Explicite spécialisation [temp.expl.spec] "explicite d'Une spécialisation de l'un quelconque des éléments suivants: (...) — membre de modèle de classe d'une classe ou d'un modèle de classe — fonction membre template d'une classe ou d'un modèle de classe peut être déclarée par une déclaration (...)" "explicite la spécialisation doit être déclarée dans un espace de noms en joignant spécialisées modèle".
    • pas sûr que je vous suivre. Je ne pense pas que la spécialisation d'un membre de modèle est un "nouveau membre", puisque le modèle est le membre. J'ai peut-être tort. Si je me trompe alors bien sûr, les modèles sont une exception à ce que je disais, puisque aussi bien que spécialisée modèles de membre à l'extérieur de la classe, vous pouvez bien sûr également instancier modèles de membre en dehors de la classe. Dans aucun des cas je pense que la classe a été "ré-ouvert", et je ne pense pas qu'il permet à l'interlocuteur.
    • Une définition de modèle décrit un ensemble potentiellement infini de spécialisations. Vous pouvez afficher un modèle de fonction de la déclaration que le "potentiel" de la déclaration d'un ensemble infini de fonctions, et un membre modèle de déclaration que le "potentiel" de la déclaration d'un ensemble infini de membres. Vous pouvez compter un nouveau membre de modèle explicite de la spécialisation en tant que nouveau membre ou pas. Mon point est que 1) un membre de modèle explicite de la spécialisation est déclarée en dehors de la définition de la classe 2) son corps est le corps d'une fonction membre (si c'est un modèle de fonction).
    • (...) "vous pouvez bien sûr aussi instancier modèles de membre en dehors de la classe." Oui, mais vous ne pouvez pas réécrire leur définition. "Dans aucun des cas je pense que la classe a été "ré-ouverture"," Avec une spécialisation explicite, la classe peut être "ré-ouverture".
    • Vous pourrait vue comme " le "potentiel" de la déclaration d'un ensemble infini de membres, mais comme je le dis ci-dessus, je crois qu'il est incorrect de le faire. Je crois qu'il est l'un des membres, qui est le modèle. Ajouter les spécialisations à un modèle de fonction n'affecte jamais si oui ou non le modèle est choisi par les règles de recherche, il affecte uniquement la façon dont l'instanciation est généré. C'est pourquoi en général, vous devez surcharger les modèles de fonction plutôt que de se spécialiser, bien que dans le cas de membres de la classe, vous n'avez pas le choix une fois que la classe est définie, puisqu'il ne peut être ré-ouvert à ajouter les surcharges.
    • De toute façon, nous allons parler de la bonne la définition de l'expression "ré-ouvrir une classe pour ajouter de nouveaux membres", qui n'est pas pertinent pour la question. Avec le sens de la phrase que j'ai défini dans ces commentaires (spécialisée un membre modèle n'est pas "ré-ouverture pour ajouter de nouveaux membres") la déclaration que j'ai faite dans ma réponse est vrai. Avec votre définition de la phrase, l'énoncé est faux, mais peut être réalisé en ajoutant des supplémentaires de belette libellé. Les deux façons de répondre à la question, "parce que si vous laissez les membres privés de la classe de définition il n'y a pas de mécanisme d'ajouter plus tard".
    • Je ne suis pas sûr d'une discussion philosophique sur "ce que a membre est" est nécessaire ici. Un modèle membre ne peut pas être une fonction virtuelle. Donc ce n'est pas un outil général pour l'ajout de "plus tard" arbitraire membres d'une définition de classe. Un modèle de fonction membre est un peu comme un ami de la fonction de modèle, il a accès aux membres. La "ré-ouverture" est limité à l'écriture de code avec l'accès aux membres privés.

    InformationsquelleAutor Steve Jessop
  4. 2

    Le niveau d'accès n'a pas d'incidence sur la visibilité. Les fonctions privées sont visibles à un code externe et peut être sélectionné par la résolution de surcharge (qui pourrait alors entraîner un accès violoation erreur):

    class A {
    void F(int i) {}
public:
    void F(unsigned i) {}
};

int main() {
    A a;
    a.F(1); //error, void A::F(int) is private
}

    Imaginer la confusion quand cela fonctionne:

    class A {
public:
    void F(unsigned i) {}
};

int main() {
    A a;
    a.F(1);
}

//add private F overload to A
void A::F(int i) {}

    Mais de le changer pour le premier code de résolution de surcharge pour sélectionner une fonction différente. Et que dire de l'exemple suivant?

    class A {
public:
    void F(unsigned i) {}
};

//add private F overload to A
void A::F(int i) {}

int main() {
    A a;
    a.F(1);
}

    Ou voici un autre exemple de ce qui va pas:

    //A.h
class A {
public:
    void g() { f(1); }
    void f(unsigned);
};

//A_private_interface.h
class A;
void A::f(int);

//A.cpp
#include "A_private_interface.h"
#include "A.h"

void A::f(int) {}
void A::f(unsigned) {}

//main.cpp
#include "A.h"

int main() {
    A().g();
}
    • Eh, cela semble être la seule à remarquer que la surcharge des règles doivent changer.
    • Pour prendre de la visibilité en compte et sélectionnez pas inaccessible méthodes? C++ a une bonne raison pour la façon dont il fonctionne. Par exemple: stackoverflow.com/questions/644461/...
    • Je ne pense pas que la surcharge des règles, il faudrait prendre l'accessibilité en compte. Ils avaient probablement juste être définies afin de prendre en compte que les fonctions de membre qui sont déclarées avant le point d'utilisation -- donc, si votre fonction membre privée est dans la définition de la classe, puis il s'arrête a.F(1) de la compilation en code client, et si il est ajouté que dans A.cpp alors qu'elle n'affecte pas de code client, mais n'affecte pas la .rpc. C'est déjà comment les espaces de travail (si vous ajoutez plus de surcharges, ils peuvent être sélectionnés). Il y a une certaine complexité requis, par exemple ce qui se passe avec les deux en phase de recherche.
    • Bien sûr, cela pourrait être fait, mais je pense qu'il pourrait être tout à fait un changement significatif. Par exemple, actuellement, le champ d'application pour les membres de la classe est l'ensemble de la classe, avant même que le membre de la classe est déclarée. Je ne pense pas que la complexité est justifiée, car elle ne résout qu'un cas particulier du problème sous-jacent qui est la compilation C++ modèle, et il existe déjà des solutions de contournement pour résoudre ce cas particulier.
    • Je suis d'accord que le changement n'est pas nécessaire, je suis juste à imaginer la confusion, comme indiqué, et je ne pense pas que c'est toute cette confusion. Les membres de la classe déclarée dans la définition de classe pourrait bien sûr continuer à être visible de n'importe où dans la classe comme avant. Les membres ajoutés par cet hypothétique nouveau mécanisme aurait visibilité différente, puisque c'est tout l'objet de ce nouveau mécanisme.
    • Je ne sais pas, ça semble assez mauvais pour moi. Par exemple, il est de l'ajout de nouvelles opportunités de violer l'ODR sans rien évidemment être définies deux fois. De toute façon, ne pas imaginer votre propre confusion, imaginer le désarroi de quelqu'un qui n'est pas encore parfaitement à l'aise avec des choses comme SFINAE et deux en phase de recherche de nom.
    • Avec c++11, les surcharges peut être explicitement supprimé avec = delete de la syntaxe.

    InformationsquelleAutor bames53
  5. 1

    L'une des raisons est qu'en C++ les amis peuvent accéder à vos soldats. Pour les amis pour y accéder, les amis de la connaître.

    • Eh bien... c'est de la putain de but de friends.
    InformationsquelleAutor Rob K
  6. 0

    Membres privés d'une classe sont toujours membres de la classe, de sorte qu'ils doivent être déclarés, comme la mise en œuvre d'autres membres du public peuvent dépendre du fait que la méthode privée. Déclarant permettra au compilateur de comprendre un appel à cette fonction comme un appel de fonction membre.

    Si vous avez une méthode n'est utilisée int la .cpp fichier et ne dépend pas de l'accès direct à d'autres membres privés de la classe, envisager de passer à un anonyme, un espace de noms. Ensuite, il n'a pas besoin d'être déclarée dans le fichier d'en-tête.

    • oui, mais pourquoi le spec-dire qu'elles doivent être déclarées? Vous n'avez pas répondu à la question. Il y a déjà des règles en disant: les fonctions doivent être déclarées avant d'appeler, si ce n'est pas ça. (l'espace de noms astuce est bonne tout de même)
    InformationsquelleAutor Prashant Kumar
  7. 0

    Il ya un couple de raisons pourquoi les fonctions privées doivent être déclarés.

    Première Erreur De Compilation Des Contrôles

    le point de modificateurs d'accès est d'attraper certaines classes (no pun intended) des erreurs de programmation au moment de la compilation. Privé des fonctions sont des fonctions qui, si quelqu'un appelé de l'extérieur de la classe, ce serait un bug, et vous voulez savoir à ce sujet dès que possible.

    Deuxième Casting et de l'Héritage

    Prises à partir de la norme C++:

    3 [ Note: Un membre privé de la classe de base peut être inaccessible hérité d'un nom de membre, mais accessible directement. Parce que les règles sur le pointeur de conversions (4.10) et les conversions explicites (5.4), une conversion d'un pointeur vers une classe dérivée vers un pointeur vers un inaccessible de la classe de base peut être mal formé si une conversion implicite est utilisé, mais bien formé si un cast explicite est utilisé.

    3ème Amis

    Amis montrent les uns des autres il y a des soldats. Une méthode privée ne peut être appel par une autre classe qui est un ami.

    4ème Générale de l'esprit et la Bonne Conception

    Jamais travaillé sur un projet avec une autre de 100 développeurs. Avoir un standard et un ensemble de règle permet de maintenir maintenable. déclarer quelque chose de privé, a un sens précis à chacun dans le groupe.

    Également ce flux en bonne OO principes de conception. Ce que pour exposer et ce n'est pas

    • Ce n'est pas vouloir Ancurio veut savoir. Il se demande pourquoi nous ne pouvons pas (certains) garder privé fonctionne comme un secret en premier lieu. Vous ne pouvez pas appeler une fonction que vous ne connaissez pas.
    • le compilateur doit savoir que son privé. de sorte qu'il peut expulser un moment de la compilation d'avertissement lorsque quelqu'un d'autre essaie de l'appeler...rien n'est jamais vraiment un secret
    • c'est vrai, mais si privé non virtuelle fonctions n'étaient pas déclarés publique dans un fichier d'en-tête (et donc de la documentation) en premier lieu, ne serait d'essayer de l'appeler. Sauf peut-être pour moi-même... auquel cas c'est l'avertissement (n'est-ce pas une erreur en fait?) ne font sens.
    • accepter pour les amis ...parce que les amis se montrent leurs soldats
    • cela a également eu à faire face avec la façon dont les choses sont exprimés à d'autres types de
    • à partir de la norme 3 [ Note: Un membre privé de la classe de base peut être inaccessible hérité d'un nom de membre, mais accessible directement. Parce que les règles sur le pointeur de conversions (4.10) et les conversions explicites (5.4), une conversion d'un pointeur vers une classe dérivée vers un pointeur vers un inaccessible de la classe de base peut être mal formé si une conversion implicite est utilisé, mais bien formé si un cast explicite est utilisé.
    • informations utiles appartient de réponses pas de commentaires. Les commentaires peuvent être supprimés sans avertissement.

    InformationsquelleAutor nate_weldon