Guide de style C ++ de Google. Partie 4

Partie 1. Introduction

...

Partie 4. Classes

...





Cet article est une traduction d'une partie du guide de style C ++ de Google en russe.

Article original (fork sur github), traduction mise à jour .

Des classes

Les classes sont le bloc de construction principal en C ++. Et, bien sûr, ils sont souvent utilisés. Cette section décrit les règles de base et les interdictions à suivre lors de l'utilisation des classes.

Code dans le constructeur

N'appelez pas de méthodes virtuelles dans le constructeur. Évitez les initialisations qui peuvent échouer (et il n'y a aucun moyen de signaler une erreur. Remarque: notez que Google n'aime pas les exceptions).



Définition



En général, toute initialisation peut être effectuée dans un constructeur (c'est-à-dire que toute initialisation peut être effectuée dans un constructeur).



Par

• Pas besoin de s'inquiéter de la classe non initialisée.
• Les objets qui sont entièrement initialisés dans le constructeur peuvent être const et sont également plus faciles à utiliser dans des conteneurs et des algorithmes standard.

Contre

• Si des fonctions virtuelles sont appelées dans le constructeur, les implémentations de la classe dérivée ne sont pas appelées. Même si la classe n'a plus de descendants, cela pourrait devenir un problème à l'avenir.
• ( ) ( ).
• , ( — ) . : bool IsValid(). .
• . , , .

Les



constructeurs de verdict ne doivent pas appeler de fonctions virtuelles. Dans certains cas (si autorisé), les erreurs de conception peuvent être traitées par l'arrêt du programme. Sinon, considérez le modèle de méthode d'usine ou utilisez Init () (plus de détails ici: TotW # 42 ). Utilisez Init () uniquement si l'objet a des indicateurs d'état qui permettent d'appeler certaines fonctions publiques (car il est difficile de travailler entièrement avec un objet partiellement construit).

Conversions implicites

Ne déclarez pas de conversions implicites. Utilisez le mot clé explicite pour les opérateurs de conversion de type et les constructeurs à argument unique.



Définition



Les conversions implicites permettent à un objet d'un type source d'être utilisé là où un autre type (type de destination) est attendu, par exemple en passant un argument int à une fonction qui attend un double .



En plus des conversions implicites spécifiées par le langage de programmation, vous pouvez également définir vos propres conversions personnalisées en ajoutant les membres appropriés à la déclaration de classe (source et destination). La conversion implicite côté source est déclarée comme type opérateur + récepteur (par exemple, opérateur bool () ). La conversion implicite côté récepteur est implémentée par un constructeur qui prend le type source comme seul argument (en plus des arguments par défaut).



Le mot-clé explicite peut être appliqué à un constructeur ou à un opérateur de conversion pour indiquer explicitement qu'une fonction ne peut être utilisée qu'en cas de correspondance de type explicite (par exemple, après une conversion). Cela s'applique non seulement aux conversions implicites, mais également aux listes d'initialisation en C ++ 11:

class Foo {
  explicit Foo(int x, double y);
  ...
};
void Func(Foo f);

      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
    

Func({42, 3.14});  // 

      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
    

Cet exemple de code n'est techniquement pas une conversion implicite, mais le langage le traite comme s'il était censé être explicite .



Par

• , .
• , string_view std::string const char*.
• .

• , ( ).
• , : , .
• , .
• explicit : , .
• , . — , .
• , , , .

Les opérateurs de conversion de verdict et les constructeurs à argument unique doivent être déclarés avec le mot clé explicite . Il y a aussi une exception: les constructeurs de copie et de déplacement peuvent être déclarés sans explicite , car ils n'effectuent pas de conversion de type. En outre, des conversions implicites peuvent être nécessaires dans le cas de classes wrapper pour d'autres types (dans ce cas, assurez-vous de demander à votre gestion en amont l'autorisation d'ignorer cette règle importante).



Les constructeurs qui ne peuvent pas être appelés avec un seul argument peuvent être déclarés sans explicite . Constructeurs acceptant un seul std :: initializer_listdoit également être déclaré sans explicite pour prendre en charge l'initialisation de la copie (par exemple, MyType m = {1, 2}; ).

Types copiables et déplaçables

L'interface publique de la classe doit indiquer explicitement la possibilité de copier et / ou déplacer, ou vice versa, tout interdire. Prend en charge la copie et / ou le déplacement uniquement si ces opérations ont un sens pour votre type.



Définition Un



type réadressable est un type qui peut être initialisé ou attribué à partir de valeurs temporaires.



Type copiable - peut être initialisé ou attribué à partir d'un autre objet du même type (c'est-à-dire identique à celui qui peut être déplacé), à condition que l'objet d'origine reste inchangé. Par exemple , std :: unique_ptr <int> peut être déplacé, mais pas le type à copier (car la valeur de l'objet std :: unique_ptr <int> d'origine doit changer lorsqu'elle est affectée à la cible). intet std :: string sont des exemples de types relocalisables qui peuvent également être copiés: pour int, les opérations de déplacement et de copie sont les mêmes, pour std :: string l' opération de déplacement nécessite moins de ressources que copy.



Pour les types définis par l'utilisateur, la copie est spécifiée par le constructeur de copie et l'opérateur de copie. Le mouvement est spécifié soit par le constructeur de déplacement avec l'opérateur de déplacement, soit (s'il n'est pas présent) par les fonctions de copie correspondantes.



Les constructeurs de copie et de déplacement peuvent être appelés implicitement par le compilateur, par exemple, lors du passage d'objets par valeur.



Par



Les objets de types copiables et déplaçables peuvent être passés et reçus par valeur, ce qui rend l'API plus simple, plus sûre et plus polyvalente. Dans ce cas, il n'y a aucun problème avec la propriété de l'objet, son cycle de vie, le changement de valeur, etc., et il n'est pas non plus nécessaire de les spécifier dans le "contrat" ​​(tout cela est différent du passage d'objets par pointeur ou référence). La communication paresseuse entre le client et l'implémentation est également empêchée, ce qui rend le code beaucoup plus facile à comprendre, à maintenir et à optimiser pour le compilateur. Ces objets peuvent être utilisés comme arguments pour d'autres classes qui nécessitent de passer par valeur (par exemple, la plupart des conteneurs), et en général, ils sont plus flexibles (par exemple, lorsqu'ils sont utilisés dans des modèles de conception).



Les constructeurs de copie / déplacement et les opérateurs d'assignation associés sont généralement plus faciles à définir que des alternatives telles que Clone () , CopyFrom () ou Swap () car le compilateur peut générer les fonctions requises (implicitement ou avec = default ). Elles (fonctions) sont faciles à déclarer et vous pouvez être sûr que tous les membres de la classe seront copiés. Les constructeurs (copier et déplacer) sont généralement plus efficaces car ne nécessitent pas d'allocation de mémoire, une initialisation séparée, des affectations supplémentaires, sont bien optimisées (voir élision de copie ).



Les opérateurs de déplacement vous permettent de manipuler efficacement (et implicitement) les ressources rvalue des objets. Cela facilite parfois le codage.



Contre



Certains types ne doivent pas nécessairement être copiables et la prise en charge des opérations de copie peut être contre-intuitive ou entraîner un fonctionnement incorrect. Les types de singletones ( Registerer ), les objets à nettoyer (par exemple, en sortie de champ) ( Cleanup ) ou contenant des données uniques ( Mutex ) sont, dans leur sens, non copiables. En outre, les opérations de copie pour les classes de base qui ont des descendants peuvent entraîner un découpage d'objets.... Les opérations de copie par défaut (ou mal écrites) peuvent entraîner des erreurs difficiles à détecter.



Les constructeurs de copie sont appelés implicitement et cela est facile à ignorer (en particulier pour les programmeurs qui écrivaient auparavant dans des langages où les objets sont passés par référence). Vous pouvez également réduire les performances en effectuant des copies inutiles.



Verdict L'



interface publique de chaque classe doit indiquer explicitement les opérations de copie et / ou de déplacement qu'elle prend en charge. Cela se fait généralement dans la section publique sous la forme de déclarations explicites des fonctions requises ou en les déclarant comme delete.



En particulier, la classe copiée doit déclarer explicitement les opérations de copie; seule une classe réadressable doit déclarer explicitement les opérations de déplacement; une classe non copiable / non déplaçable doit explicitement refuser ( = supprimer ) les opérations de copie. La déclaration ou la suppression explicite des quatre fonctions de copie et de déplacement est également autorisée, bien que non obligatoire. Si vous implémentez l'opérateur de copie et / ou de déplacement, vous devez également créer le constructeur correspondant.

class Copyable {
 public:
  Copyable(const Copyable& other) = default;
  Copyable& operator=(const Copyable& other) = default;
  //       (..  )
};
class MoveOnly {
 public:
  MoveOnly(MoveOnly&& other);
  MoveOnly& operator=(MoveOnly&& other);
  //     .  ( )    :
  MoveOnly(const MoveOnly&) = delete;
  MoveOnly& operator=(const MoveOnly&) = delete;
};
class NotCopyableOrMovable {
 public:
  //       
  NotCopyableOrMovable(const NotCopyableOrMovable&) = delete;
  NotCopyableOrMovable& operator=(const NotCopyableOrMovable&)
      = delete;
  //     (),    :
  NotCopyableOrMovable(NotCopyableOrMovable&&) = delete;
  NotCopyableOrMovable& operator=(NotCopyableOrMovable&&)
      = delete;
};

      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
    

Les déclarations ou suppressions de fonctions décrites peuvent être omises dans des cas évidents:

• Si une classe ne contient pas de section privée (par exemple, une structure ou une classe d'interface), la possibilité de copie et la relocalisation peuvent être déclarées via une propriété similaire de n'importe quel membre public.
• , . , , .
• , () /, / (.. ). / . .

Un type ne doit pas être déclaré copiable / relocalisable à moins qu'un programmeur ordinaire ne comprenne la nécessité de ces opérations, ou si les opérations sont très gourmandes en ressources et en performances. Les opérations de déplacement pour les types copiés sont toujours une optimisation des performances, mais elles sont en revanche une source potentielle de bogues et de complications. Par conséquent, ne déclarez pas les opérations de déplacement à moins qu'elles ne fournissent des gains de performances significatifs par rapport à la copie. En général, il est souhaitable (si des opérations de copie sont déclarées pour une classe) de tout concevoir de manière à ce que les fonctions de copie par défaut soient utilisées. Et assurez-vous de vérifier l'exactitude de toutes les opérations par défaut.



En raison du risque de «découpage», il est préférable d'éviter les opérateurs de copie publique et de déplacement pour les classes que vous prévoyez d'utiliser comme classes de base (et de préférence ne pas hériter d'une classe avec de telles fonctions). Si vous avez besoin de rendre la classe de base copiable, créez une fonction virtuelle publique Clone () et un constructeur de copie protégée afin que la classe dérivée puisse les utiliser pour implémenter des opérations de copie.

Structures vs classes

Utilisez des structures uniquement pour les objets passifs qui stockent des données. Dans d'autres cas, utilisez les classes ( classe ).



Les mots-clés struct et class sont presque identiques en C ++. Cependant, nous avons notre propre compréhension de chaque mot-clé, alors utilisez celui qui convient à son objectif et à sa signification.



Les structures doivent être utilisées pour les objets passifs, uniquement pour le transfert de données. Ils peuvent avoir leurs propres constantes, mais il ne devrait y avoir aucune fonctionnalité (à l'exception possible des fonctions get / set). Tous les champs doivent être publics, disponibles pour un accès direct, ce qui est préférable à l'utilisation des fonctions get / set. Les structures ne doivent pas contenir d'invariants (par exemple, des valeurs calculées), qui sont basés sur des dépendances entre différents champs de la structure: la possibilité de modifier directement les champs peut invalider l'invariant. Les méthodes ne doivent pas restreindre l'utilisation de la structure, mais peuvent attribuer des valeurs aux champs: c.-à-d. comme constructeur, destructeur ou fonctions Initialize () , Reset () .



Si des fonctionnalités supplémentaires sont requises dans le traitement des données ou des invariants, il est préférable d'utiliser les classes ( classe ). De plus, en cas de doute, utilisez des classes.



Dans certains cas ( modèles de méta-fonctions , traits, certains foncteurs) par souci de cohérence avec la STL, il est permis d'utiliser des structures au lieu de classes.



N'oubliez pas que les variables des structures et des classes sont nommées dans des styles différents.

Structures vs paires et tuples

Si des éléments individuels d'un bloc de données peuvent être nommés de manière significative, il est préférable d'utiliser des structures au lieu de paires ou de tuples.



Tout en utilisant des paires et tuples évite de réinventer la roue avec votre propre type et vous permettra d' économiser beaucoup de temps l' écriture du code, des champs avec des noms significatifs ( au lieu de .first , .SECOND, ou std :: get <X> ) sera plus facile à lire lors de la lecture du code. Et bien que C ++ 14 ajoute l'accès au type ( std :: get <Type> , et le type doit être unique) pour les tuples en plus de l'accès à l'index , le nom du champ est beaucoup plus informatif que le type.



Les paires et les tuples sont appropriés dans le code où il n'y a pas de distinction spéciale entre les éléments d'une paire ou d'un tuple. Ils sont également tenus de travailler avec du code ou des API existants.

Héritage

La composition de classe est souvent plus appropriée que l'héritage. Lorsque vous utilisez l'héritage, rendez-le public .



Définition



Lorsqu'une classe enfant hérite d'une classe de base, elle inclut les définitions de toutes les données et opérations de la base. "L'héritage d'interface" est l'héritage d'une classe de base abstraite pure (aucun état ni aucune méthode n'y sont définis). Tout le reste est "héritage d'implémentation".



Par



L'héritage d'implémentation réduit la taille du code en réutilisant des parties de la classe de base (qui devient une partie de la nouvelle classe). Car l'héritage est une déclaration à la compilation, il permet au compilateur de comprendre la structure et de trouver des erreurs. L'héritage d'interface peut être utilisé pour que la classe prenne en charge l'API requise. Et aussi, le compilateur peut trouver des erreurs si la classe ne définit pas la méthode requise de l'API héritée.



Inconvénients



Dans le cas de l'héritage d'implémentation, le code commence à se brouiller entre les classes de base et enfant, ce qui peut compliquer la compréhension du code. En outre, la classe enfant ne peut pas remplacer le code des fonctions non virtuelles (ne peut pas modifier leur implémentation).



L'héritage multiple est encore plus problématique et conduit parfois à une dégradation des performances. Souvent, la baisse des performances lors du passage de l'héritage unique à l'héritage multiple peut être plus importante que la transition des fonctions régulières vers les fonctions virtuelles. C'est aussi une étape de l'héritage multiple à l'héritage rhombique, ce qui conduit déjà à l'ambiguïté, à la confusion et, bien sûr, aux bugs.



Verdict



Tout héritage doit être public . Si vous souhaitez le rendre privé , il est préférable d'ajouter un nouveau membre avec une instance de la classe de base.



N'abusez pas de l'héritage d'implémentation. La composition des classes est souvent préférée. Essayez de limiter l'utilisation de la sémantique d'héritage "is": Bar , vous pouvez hériter du Foo , si je peux dire que le Bar "est» le Foo (c'est-à-dire, là où on utilise le Foo , vous pouvez également utiliser le Bar ).



Protected ( protected ) n'exécute que les fonctions qui devraient être disponibles pour les classes enfants. Notez que les données doivent être privées.



Déclarez explicitement les remplacements de fonction / destructeur virtuels à l'aide de spécificateurs: soit un remplacement, soit (si nécessaire) final . N'utilisez pas le spécificateur virtuel lors de la substitution de fonctions. Explication: Une fonction ou un destructeur marqué override ou final mais pas virtuel ne sera tout simplement pas compilé (ce qui permet de détecter les erreurs courantes). Les prescripteurs fonctionnent également comme de la documentation; et s'il n'y a pas de spécificateurs, le programmeur sera obligé de vérifier toute la hiérarchie pour clarifier la virtualité de la fonction.



L'héritage multiple est autorisé, cependant l'héritage multiple la mise en œuvre n'est pas du tout recommandée par le mot.

Surcharge de l'opérateur

Surcharger les opérateurs aussi raisonnablement que possible. N'utilisez pas de littéraux personnalisés.



La détermination du



code C ++ permet à l'utilisateur de remplacer les opérateurs intégrés en utilisant l' opérateur de mot-clé et le type d'utilisateur comme l'un des paramètres; également l' opérateur vous permet de définir de nouveaux littéraux en utilisant l' opérateur "" ; vous pouvez également créer des fonctions de conversion comme l' opérateur bool () .



Par



L'utilisation de la surcharge d'opérateurs pour les types définis par l'utilisateur (similaire aux types intégrés) peut rendre votre code plus concis et intuitif. Les opérateurs surchargés correspondent à certaines opérations (par exemple, == , < , = et << ) et si le code suit la logique d'application de ces opérations, les types définis par l'utilisateur peuvent être clarifiés et utilisés lorsque vous travaillez avec des bibliothèques externes qui reposent sur ces opérations.



Les littéraux personnalisés sont un moyen très efficace de créer des objets personnalisés.



Contre

• (, ) — , , .
• , .
• , , .
• , , .
• , .
• / ( ), «» . , foo < bar &foo < &bar; .
• . & , . &&, || , () ( ) .
• , . , .
• (UDL) , C++ . : «Hello World»sv std::string_view(«Hello World»). , .
• Car aucun espace de noms n'est spécifié pour l'UDL, vous devrez soit utiliser une directive using (ce qui est interdit ) ou une déclaration using (qui est également interdite (dans les fichiers d'en-tête) , sauf si les noms importés font partie de l'interface affichée dans le fichier d'en-tête). Pour de tels fichiers d'en-tête, il est préférable d'éviter les suffixes UDL, et il est souhaitable d'éviter les dépendances entre les littéraux qui sont différents dans l'en-tête et le fichier source.

Verdict



Définissez les opérateurs surchargés uniquement si leur signification est évidente, claire et cohérente avec la logique générale. Par exemple, utilisez | au sens de l'opération OR; implémenter la logique de canal à la place n'est pas une bonne idée.



Définissez des opérateurs uniquement pour vos propres types, faites-le dans le même en-tête et le même fichier source, et dans le même espace de noms. En conséquence, les opérateurs seront disponibles au même endroit que les types eux-mêmes, et le risque de définitions multiples est minime. Dans la mesure du possible, évitez de définir des opérateurs comme des modèles. vous devez faire correspondre n'importe quel ensemble d'arguments de modèle. Si vous définissez un opérateur, définissez-lui également des "frères et sœurs". Et veillez à la cohérence des résultats qu'ils renvoient. Par exemple, si vous définissez l'opérateur < , définissez tous les opérateurs de comparaison et assurez-vous que les opérateurs < et > ne renvoient jamais true pour les mêmes arguments.



Il est souhaitable de définir des opérateurs binaires immuables comme des fonctions externes (non membres). Si l'opérateur binaire est déclaré membre de la classe, la conversion implicite peut être appliquée à l'argument de droite, mais pas à l'argument de gauche. Cela peut être un peu frustrant pour les programmeurs si (par exemple) le code a <b se compilera, mais b <a ne le fera pas.



Pas besoin d'essayer de contourner les remplacements d'opérateurs. Si une comparaison (ou une fonction d'affectation et de sortie) est requise, il est préférable de définir == (ou = et << ) au lieu de vos Equals () , CopyFrom () et Imprimer vers () . Inversement, vous n'avez pas besoin de redéfinir un opérateur simplement parce que les bibliothèques externes l'attendent. Par exemple, si le type de données ne peut pas être trié et que vous souhaitez le stocker dans std :: set , il est préférable de créer une fonction de comparaison personnalisée et de ne pas utiliser l'opérateur < .



Ne remplacez pas && , || , , (Comma) ou unaire & . Ne remplacez pas l' opérateur "" , c'est-à-dire n'ajoutez pas vos propres littéraux. N'utilisez pas de littéraux précédemment définis (y compris la bibliothèque standard et autres).



Informations supplémentaires:

La conversion de type est décrite dans la section sur les conversions implicites . L'opérateur = est écrit dans le constructeur de copie . Le sujet de la surcharge << pour travailler avec des flux est traité dans les flux . Vous pouvez également vous familiariser avec les règles de la section sur les fonctions de surcharge , qui conviennent également aux opérateurs.

Accès aux membres de la classe

Rendez toujours les données de classe privées , à l'exception des constantes . Cela simplifie l'utilisation des invariants en ajoutant les fonctions d'accès les plus simples (souvent constantes).



Il est permis de déclarer les données de classe comme protégées pour une utilisation dans des classes de test (par exemple, lors de l'utilisation de Google Test ) ou dans d'autres cas similaires.

Procédure d'annonce

Placez des annonces similaires au même endroit, faites apparaître les parties communes.



La définition de classe commence généralement par une partie du public: , va plus loin protégée: et privé: . Ne spécifiez pas de sections vides.



Dans chaque section, regroupez les déclarations similaires. L'ordre préféré est les types (y compris typedef , using , classes et structures imbriquées), constantes, méthodes de fabrique, constructeurs, opérateurs d'affectation, destructeurs, autres méthodes, données membres.



Ne placez pas de définitions de méthode volumineuses dans la définition de classe. Habituellement, seules les méthodes triviales, très courtes ou critiques pour les performances sont «intégrées» dans la définition de classe. Voir aussi Fonctions en ligne .