Dois-je utiliser des #define, enum ou const?

Combiner les stratégies pour réduire les inconvénients d'une approche unique. Je travaille dans les systèmes embarqués, donc la solution suivante est basée sur le fait que les entier et les opérateurs sur les bits sont rapides, peu de mémoire & faible flash d'utilisation.

Place enum dans un espace de noms pour éviter les constantes de polluer l'espace de noms global.

namespace RecordType {

Un enum déclare et définit un temps de compilation vérifié tapé. Utilisez toujours le temps de compilation type de vérification pour vous assurer que les arguments et les variables sont donné le bon type. Il n'est pas nécessaire pour la définition de type en C++.

enum TRecordType { xNew = 1, xDeleted = 2, xModified = 4, xExisting = 8,

Créer un autre membre pour un état non valide. Cela peut être utile en tant que code d'erreur; par exemple, lorsque vous voulez retourner à l'état, mais l'opération d'e/S échoue. Il est également utile pour le débogage; l'utiliser dans l'initialisation des listes et des destructeurs de savoir si la valeur de la variable doit être utilisée.

xInvalid = 16 };

Considérez que vous avez deux objectifs pour ce type. Pour suivre l'état actuel du dossier et de créer un masque pour sélectionner des enregistrements dans certains états. Créer une fonction en ligne pour tester si la valeur de type est valable pour votre objectif, en tant que marqueur de l'état par rapport à un état de masque. Cela permettra de repérer les bugs que l' typedef est juste un int et une valeur telle que 0xDEADBEEF peut être dans votre variable non initialisée par ou mispointed variables.

inline bool IsValidState( TRecordType v) {
    switch(v) { case xNew: case xDeleted: case xModified: case xExisting: return true; }
    return false;
}

 inline bool IsValidMask( TRecordType v) {
    return v >= xNew  && v < xInvalid ;
}

Ajouter un using directive, si vous souhaitez utiliser le type souvent.

using RecordType ::TRecordType ;

La valeur de vérification de fonctions sont utiles dans affirme pour piéger les mauvaises valeurs dès qu'ils sont utilisés. Le plus vite vous attraper un bug lors de l'exécution, le moins de dégâts qu'il peut faire.

Voici quelques exemples pour mettre tout cela ensemble.

void showRecords(TRecordType mask) {
    assert(RecordType::IsValidMask(mask));
    //do stuff;
}

void wombleRecord(TRecord rec, TRecordType state) {
    assert(RecordType::IsValidState(state));
    if (RecordType ::xNew) {
    //...
} in runtime

TRecordType updateRecord(TRecord rec, TRecordType newstate) {
    assert(RecordType::IsValidState(newstate));
    //...
    if (! access_was_successful) return RecordType ::xInvalid;
    return newstate;
}

La seule façon de garantir la valeur correcte de la sécurité est d'utiliser une classe dédiée à la surcharge de l'opérateur et qui est laissé comme exercice pour un autre lecteur.

Avez-vous exclu std::bitset? Jeux de drapeaux est ce que c'est. Ne

typedef std::bitset<4> RecordType;

puis

static const RecordType xNew(1);
static const RecordType xDeleted(2);
static const RecordType xModified(4);
static const RecordType xExisting(8);

Parce qu'il y a un tas de surcharge de l'opérateur pour bitset, vous pouvez maintenant faire

RecordType rt = whatever;      //unsigned long or RecordType expression
rt |= xNew;                    //set 
rt &= ~xDeleted;               //clear 
if ((rt & xModified) != 0) ... //test

Ou quelque chose de très similaire à celle - j'apprécierais toute correction, puisque je n'ai pas testé cette. Vous pouvez aussi consulter les bits par index, mais il est généralement préférable de se définir qu'un ensemble de constantes, et RecordType constantes sont probablement plus utile.

En supposant que vous avez exclu bitset, je vote pour la enum.

Je ne crois pas que le casting de l'enum est un inconvénient sérieux - OK, donc c'est un peu bruyant, et l'affectation d'une valeur à un enum est un comportement indéterminé, donc il est théoriquement possible de se tirer dans le pied sur certains inhabituelle C++ implémentations. Mais si vous ne le faites qu'en cas de nécessité (ce qui est quand il va partir int enum iirc), il est parfaitement normal de code que les gens ont vu avant.

Je suis dubitatif sur tout l'espace du coût de l'enum, trop. uint8 des variables et des paramètres ne sera probablement pas utiliser le moins de la pile que ints, afin de stockage uniquement dans les classes questions. Il y a certains cas où l'emballage de plusieurs octets dans une struct va gagner (dans ce cas, vous pouvez lancer les énumérations dans et hors de uint8 de stockage), mais normalement rembourrage va tuer le bénéfice de toute façon.

Donc l'enum n'a pas les inconvénients par rapport aux autres, et comme un avantage vous donne un peu de type de sécurité (vous ne pouvez pas affecter une valeur entière aléatoire, sans explicitement casting) et propres manières de se référer à tout.

De préférence je voudrais aussi mettre le "= 2" dans l'enum, par la manière. Il n'est pas nécessaire, mais un "principe de moindre étonnement", suggère que tous les 4 définitions doivent se ressemblent.

Si possible ne PAS utiliser les macros. Ils ne sont pas trop admiré quand il s'agit de C++ moderne.

Avec les définit-je perdre de sécurité de type

Pas nécessairement...

//signed defines
#define X_NEW      0x01u
#define X_NEW      (unsigned(0x01))  //if you find this more readable...

et avec enum je perds de l'espace (entiers)

Pas nécessairement - mais vous n'avez pas à être explicite dans les points de stockage...

struct X
{
    RecordType recordType : 4;  //use exactly 4 bits...
    RecordType recordType2 : 4;  //use another 4 bits, typically in the same byte
    //of course, the overall record size may still be padded...
};

et probablement d'avoir à jeter quand je veux faire l'opération au niveau du bit.

Vous pouvez créer des opérateurs de prendre la douleur hors de l':

RecordType operator|(RecordType lhs, RecordType rhs)
{
    return RecordType((unsigned)lhs | (unsigned)rhs);
}

Avec const je pense que j'ai aussi perdre de sécurité de type depuis un hasard uint8 pourrait obtenir par erreur.

La même chose peut arriver avec n'importe quel de ces mécanismes: la portée et la valeur des contrôles sont normalement orthogonale à la sécurité de type (bien que définies par l'utilisateur-types - c'est à dire vos propres classes - peut faire valoir des "invariants" à propos de leurs données). Avec les énumérations, le compilateur est libre de choisir un plus grand type de l'hôte, les valeurs, et non initialisée, corrompus ou tout simplement miss-ensemble enum variable pourrait encore se retrouver interpretting sa séquence de bits qu'un certain nombre, vous vous attendez à - comparaison de l'inégalité à l'une quelconque de l'énumération des identifiants, toute combinaison d'entre eux, et 0.

Est-il un autre moyen le plus propre? /Sinon, que ferais-tu et pourquoi?

Bien, à la fin de l'testés et fiables de style C OU binaire de énumérations fonctionne très bien une fois que vous avez champs de bits et d'exploitants dans l'image. Vous pouvez encore améliorer votre résistance avec quelques fonctions de validation et d'affirmations comme dans mat_geek de réponse; des techniques souvent également applicables à la manipulation de string, int, double, valeurs, etc..

On pourrait dire que c'est plus "propre":

enum RecordType { New, Deleted, Modified, Existing };

showRecords([](RecordType r) { return r == New || r == Deleted; });

Je suis indifférent: les bits de données pack plus serré, mais le code augmente de manière significative... dépend de la façon dont beaucoup d'objets que vous avez, et la lamdbas - beaux soient - ils, sont toujours messier et plus dur pour obtenir le droit de bit-à-bit Rup.

BTW /- l'argument de la sécurité des threads est assez faible à mon humble avis - les annales comme un arrière-plan de l'examen plutôt que de devenir un dominant la prise de force motrice; le partage d'un mutex à travers le bitfields est plus probable que la pratique, même si pas au courant de leur emballage (mutex sont relativement volumineux de données des membres - je avoir à se soucier vraiment de la performance à envisager d'avoir plusieurs mutex sur les membres d'un objet, et j'aurais l'air assez attentivement avis ils étaient des champs de bits). Tous les sous-mot-taille type pourrait avoir le même problème (par exemple, un uint8_t). De toute façon, vous pourriez essayer atomique compare-and-swap opérations de style si vous êtes désespéré pour accroître la concurrence.

Si vous voulez que le type de sécurité de classes, avec la commodité de l'énumération de la syntaxe et de la vérification du bit, envisager Coffre-fort Étiquettes en C++. J'ai travaillé avec l'auteur, et il est assez intelligent.

Méfiez-vous, cependant. En fin de compte, ce package utilise des modèles et macros!

Je ne serais probablement pas utiliser un enum pour ce genre de chose où les valeurs peuvent être combinées ensemble, plus généralement, les énumérations sont des états mutuellement exclusifs.

Mais quelle que soit la méthode que vous utilisez, afin de le rendre plus clair que ce sont ces valeurs qui sont les bits qui peuvent être combinés ensemble, utilisez cette syntaxe pour les valeurs réelles à la place:

#define X_NEW      (1 << 0)
#define X_DELETED  (1 << 1)
#define X_MODIFIED (1 << 2)
#define X_EXISTING (1 << 3)

À l'aide d'un décalage vers la gauche, il permet d'indiquer que chaque valeur est destinée à être un peu unique, il est moins probable que, plus tard, quelqu'un ferait quelque chose de mal comme ajouter une nouvelle valeur et attribuer quelque chose d'une valeur de 9.

Si vous êtes à l'aide de Qt, vous devriez jeter un oeil pour QFlags.
Le QFlags classe fournit un moyen sûr de stocker OU de combinaisons de valeurs enum.

Pas que j'aime plus-ingénieur du tout, mais parfois, dans ces cas, il peut être intéressant de créer une (petite) classe d'encapsuler cette information.
Si vous créez une classe RecordType alors il peut avoir des fonctions comme:

vide setDeleted();

vide clearDeleted();

bool isDeleted();

etc... (ou quelle que soit la convention de costumes)

Il a pu valider les combinaisons (dans le cas où toutes les combinaisons sont légales, par exemple, si les "nouveaux" et "supprimer" ne pouvaient pas être réglés à la même heure). Si vous venez d'utiliser des masques de bits, etc alors le code qui définit l'état doit valider, une classe peut encapsuler la logique aussi.

La classe peut également vous donner la possibilité de joindre significative de la journalisation des informations pour chaque état, vous pouvez ajouter une fonction pour renvoyer une chaîne de caractères de la représentation de l'état actuel etc (ou utilisez le streaming des opérateurs<<").

Pour tous que si vous êtes inquiet au sujet de stockage vous pouvez toujours avoir la classe seulement un 'char' membre de données, alors seulement prendre une petite quantité de stockage (en supposant qu'il est non virtuel). Bien sûr, en fonction du matériel, etc vous pouvez avoir des problèmes d'alignement.

Vous pourriez avoir le nombre de bit valeurs qui ne sont pas visibles par le reste du monde si ils sont à un anonyme, un espace de noms à l'intérieur de la rpc fichier plutôt que dans le fichier d'en-tête.

Si vous constatez que le code à l'aide de l'enum/#define/bitmask etc a beaucoup de "soutien" code invalide combinaisons, l'exploitation forestière, etc alors encapsulation dans une classe peut être utile d'examiner. Bien sûr, la plupart du temps de simples problèmes sont mieux avec des solutions simples...