C++, privée dans les fonctions vraiment besoin d'être dans le fichier d'en-tête?

J'ai toujours pensé que des fichiers d'en-tête comme une sorte de "interface" décrivant une classe, auquel cas il serait préférable de garder les champs privés et des fonctions dans le fichier cpp.

Je comprends que privés doivent être des champs dans l'en-tête de sorte que d'autres classes peuvent dire combien de mémoire une instance d'une classe de consommer, mais il m'est apparu que je m'apprêtais à écrire un privé fonction d'assistance, que cette fonction pourrait être faite statique, auquel cas il n'y a pas besoin d'être "une partie de la classe" à tout, il pourrait tout aussi bien être une fonction régulière dans la définition de la classe de .fichier cpp.

Puis, il m'est apparu que tous fonctions privées pourraient être ré-écrit pour être statique par l'acceptation de pointeurs/références à des champs de la classe au lieu d'attendre d'être défini dans la classe.

Cela permettrait d'éliminer la nécessité de déclarer les fonctions privées dans le fichier d'en-tête.

Je n'aime pas suivre les conventions alors maintenant, je veux vous demander, est-il considéré comme une convention établie en C++, que les non-static private fonctions devrait être dans le fichier d'en-tête? Qu'en est statique des fonctions ou des constantes statiques?

EDIT: je vais y mettre un peu de code pour expliquer ce que j'obtiens à:

.h fichier:

#ifndef SOME_CLASS_H
#define SOME_CLASS_H

class SomeClass
{
private:
    int x;
public:
    void combineWithX(int y);
};

#endif

.fichier cpp

#include "SomeClass.h"

void someHelper(int* x)
{
    *x = (*x) + 1;
}

void SomeClass::combineWithX(int y)
{
    someHelper(&x);
    x += y;
}

Noter que someHelper(int* x) dans le fichier cpp références privé membre de x dans l'esprit, mais pas directement, et n'a donc pas besoin d'apparaître dans l'en-tête. Je me demandais si ce genre de chose est considéré comme "mauvais style'

Notez que les fonctions privées doivent être demande d'ami de l'intérieur de la classe, ou bien ils ne pouvaient accéder aux membres privés. Si ils n'ont pas besoin privée membres de, peut-être que ces fonctions ne devraient pas être eux-mêmes membres à tous.
Puisque vous ne pouvez pas rouvrir une classe d'expansion une fois fermé (C++11 9.2-p2), oui, vos fonctions de membre et de membre de vars de cette catégorie doivent être accouplés dans son decl. Vous pouvez certainement faire un pimpl-mise en œuvre, si désiré.
merci, j'ai emprunté votre lien (à l'origine je l'ai lié à une aggravation de la question)
les fonctions privées peuvent être mis à l'intérieur d'un privé intérieur de la classe, de cette façon, ils n'ont pas à être dans l'en-tête. stackoverflow.com/a/28734794/463758
Voir th réponses constructives, des explications pourquoi les fonctions privées (même si ils sont statiques ou non virtuelle) doivent figurer dans la déclaration de la classe: softwareengineering.stackexchange.com/a/239175/221200 softwareengineering.stackexchange.com/a/324450/221200

InformationsquelleAutor Ghost314 | 2015-02-05

c++conventions standards

9

Je suis d'accord que c'est un problème que les détails de mise en œuvre doivent être exposés dans un fichier d'en-tête; elle interfère avec la séparation de l'interface et la mise en œuvre.

Déplacement privé des fonctions d'assistance pour être libre des fonctions dans le .cpp fichier (je suppose que c'est ce que vous entendez par "statique") ne fonctionne pas si ces fonctions ont besoin d'accéder à des variables de membre privé.

Vous pouvez être intéressé à regarder le pImpl idiome (en savoir plus)

InformationsquelleAutor M.M
19

PImpl idiome est nécessaire que
1. si vous avez besoin de déplacer membre privé 'variables' publics, de l'en-tête ( Pour le maintien de la la compatibilité binaire des nouvelles versions - Si vous ne savez pas ce que cela signifie, il n'est probablement pas un sujet de préoccupation )
2. Si cette conception le rend plus facile à comprendre
Si vous ne souhaitez déplacer membre privé 'fonctions' publics, en-tête, à l'aide d'un intérieur de classe est assez. Ce n'est pas la redirection de pénalité comme PImpl idiome.

public .h fichier
```
#ifndef SOME_CLASS_H
#define SOME_CLASS_H

class SomeClass
{
private:
    struct Private;
    int x;
public:
    void combineWithX(int y);
};

#endif
```
dans .fichier cpp
```
#include "SomeClass.h"

/** Declare all private member functions of SomeClass here
    This class can access not only private members of SomeClass
    but also friends of SomeClass. */
struct SomeClass::Private
{
  static void someHelper(SomeClass& self)
  {
    self.x = self.x + 1;
  }
};

void SomeClass::combineWithX(int y)
{
    Private::someHelper(*this);
    x += y;
}
```
SomeClass::Private peut avoir un nombre quelconque de fonctions d'assistance qui a un accès complet à tous les particuliers/les amis de SomeClass, sans avoir à déclarer un d'eux dans le fichier d'en-tête.
- Ne pas Private besoin d'être déclarée comme un ami pour qu'il l'accès des membres privés de SomeClass? friend struct Private. Je viens de vérifier si votre code compile et il fait, mais je ne comprends pas pourquoi. Normal nested class/struct ne pas obtenir toutes les autorisations spéciales de sa classe englobante.
- Je n'ai pas de mst de référence, mais ce qui a toujours travaillé sans aucun avertissement. Donc je suppose que, imbriqués struct ne obtenez l'accès complet à la enfermant struct que si elle est partie sans avoir à le marquer comme friend
- Je vois que j'étais le mélange jusqu'à mes règles de portée. S'avère une classe imbriquée a même niveau d'accès restrictions que les autres membres de données défini de sorte qu'il peut accéder aux membres privés de la classe englobante. Ce à quoi je pensais était l'inverse que la classe englobante ne peut pas accéder à la classe imbriquée internes. Cela est garanti par la norme (cpp17 n4659) - 12.2.5 couvrant classe imbriquée déclarations à la fois la déclaration de l'avant et de l'accès aux droits. Un excellent post sur le forum: cplusplus.com/forum/general/181016 Va faire usage de ce qu'il meilleur encapsule privé des fonctions de membre du
InformationsquelleAutor balki

Vous devez vous connecter pour publier un commentaire.