C++ Static Const Variable Membre D'Utilisation

Dire que j'ai une classe qui nécessite quelques constantes de la fonction. Plusieurs fonctions de membre d'exiger l'utilisation de ces constantes. Utiliser des #define, c'est mal vu, car il peut provoquer des collisions. Les constantes sont en hexadécimal modèles de 8 ou 16 bits et sont stockés u_int8_t ou uint16_t. Ces constantes ne changent pas d'exemple d'instance de la classe, et donc de la mémoire (bien que très peu de mémoire) peuvent être enregistrées par le fait d'avoir une seule copie de l'une des constantes.

Est-il rien de répréhensible, ou peut-être de meilleure façon d'accomplir la dessus au lieu de simplement faire quelque chose comme ce qui suit:

//mycode.h
//.......
class myclass {
private:
  static const uint16_t kMyClassConstant_ = 0xBEEF;
//.......
};

Merci d'avance pour l'aide.

  • Non, il n'y a rien de mal à cela. (J'espère que certains de C++ experts de ne pas avoir à me corriger. 🙂 )
  • Vous pourriez obtenir de meilleures réponses à codereview.stackexchange.com.
  • Oui, c'est une manière normale de la déclaration d'une constante globale.
  • Merci pour l'astuce concernant les autres site!
  • C'est très bien; intégrale des constantes peuvent également être créés dans un espace de noms-sûre que enums.
InformationsquelleAutor It'sPete | 2013-06-12
  1. 45

    Compte tenu de votre description de la situation, je dirais à l'aide de static const membres est une bonne approche. En C++11, vous pouvez le changer en static constexpr à souligner c'est une constante de compilation, bien que rien ne va changer efficacement comme un résultat de qui.

    Si vous vous référez à myclass::kMyClassContant_ quelque part dans le code d'une manière qui est pertinent dans le cadre de la définition de la règle (odr), esp. dans des contextes qui nécessitent une référence (y compris const-référence), le compilateur va se plaindre qu'il n'y a pas de définition de la constante. Simplement de la déclaration et l'initialisation de l'intérieur de la classe n'est pas suffisante dans ce cas. Cela peut vous obliger à séparer déclaration et définition:

    //mycode.h
class myclass {
private:
  static const uint16_t kMyClassConstant_;
};

//mycode.cpp
const uint16_t myclass::kMyClassConstant_ = 0xBEEF;

    Pour éviter le problème du maintien de séparer les déclarations et les définitions, certaines personnes préfèrent déclarer une ligne constexpr fonction au lieu d'une variable réelle:

    //mycode.h
class myclass {
private:
  static constexpr uint16_t kMyClassConstant_()
  { return 0xBEEF; }
};

    C'est un travail correct-autour de l'odr des problèmes liés à, et il ne cause pas de perte de performance. Si c'est vraiment utile dépend de la façon dont beaucoup d'une charge, il est de séparer les déclarations et les définitions de l'ordinaire constante statique. Si vous attendez de votre constantes pour ne jamais changer votre code évolue, à l'aide d'ordinaire constantes statiques avec des définitions distinctes est préférable. Mais si vous modifier les définitions des constantes souvent, d'avoir à re-compiler le fichier de définition et de re-lier à toutes les parties pertinentes du projet peut vous faire considérer la fonction de base de la solution ci-dessus comme une meilleure alternative.

    Un dernier commentaire à faire sur le type de données: la Forçant en 16 bits à l'aide de std::uint16_t peut être utile si vous avez besoin de stocker beaucoup de ces valeurs sous forme compacte. Sinon, la taille réelle peut ne pas vraiment d'importance, auquel cas std::uint_fast16_t (qui peut être supérieure à 16 bits) peut-être mieux.

    • J'ai été attentif à vos réponses, DONC, et aussi loin que je peux dire qu'ils sont les meilleurs en termes de clarification et de précision. Cela contraste avec certaines personnes avec des haut de "réputation", qui font constamment appel à la mystification plutôt que de répondre aux questions. Félicitations (+1)
    • Merci pour les éloges 🙂 j'apprécie votre rigueur dans l'étude de ma (et d'autres) AFIN de les postes!
    • Cette réponse est tout à fait utile, mais je ne comprends pas le raisonnement sur la recompilation. Je pense que l'utilisation de inline fonctions membres (dans la définition de la classe et, par conséquent, dans le fichier d'en-tête), toutes les modifications apportées aux valeurs nécessiterait recompilation de tous les clients unités de traduction (qui comprennent que le fichier d'en-tête), même si elles ne peuvent accéder directement à des personnes privées des fonctions membres. D'autre part, avec des déclarations distinctes et les définitions, les nouvelles valeurs ne modifie que la mise en œuvre du module, nécessitant une simple recompilation et juste rétablissement du lien de clients. Que du moins, pas plus.
    InformationsquelleAutor jogojapan
  2. 5

    Vous pouvez utiliser le type de traits pour mettre en œuvre cette:

    #include <type_traits>

class myclass {
private:
  typedef std::integral_constant<uint16_t , 0xBEEF> kMyClassConstant;

  //...
};

    utilisé comme myclass::kMyClassConstant::value.

    Cela montre le but de la mise en œuvre intégrale de la constante et vous empêche de modifier accidentellement en prenant une adresse de la constante.

    InformationsquelleAutor Jan Herrmann
  3. 4

    Depuis C++17, nous avons accès à inline variables, qui prennent en charge les odr-problèmes connexes. Plusieurs options:

    //mycode.h
class myclass {
    static const inline uint16_t kMyClassConstant_ = 0xBEEF;
};

    Ou, si elle peut être marquée constexpr (comme dans ce cas):

    //mycode.h
class myclass {
    static constexpr inline uint16_t kMyClassConstant_ = 0xBEEF;
};

    Qui peut se simplifier en:

    //mycode.h
class myclass {
    static constexpr uint16_t kMyClassConstant_ = 0xBEEF;
};

    Car en C++17 constexpr implique inline pour static de données des membres.

    InformationsquelleAutor Acorn