Incompatibilité enum et c++ ?

Version imprimable

18/02/2009, 10h59
coberle

Incompatibilité enum et c++ ?

Bonjour,

Je souhaite déclarer un type énuméré (enum flag {TRUE,FALSE}; ) dans un fichier Settings.h et manifestement le compilateur n'aime pas car il me crache des erreurs du genre:
Settings.h expected identifier before numeric constant
Settings.h expected `}' before numeric constant
Settings.h expected unqualified-id before numeric constant
Settings.h expected `,' or `;' before numeric constant
Settings.h expected declaration before '}' token

Y a-t-il une incompatibilité ?
Bien cordialement,
Christian
18/02/2009, 11h07
3DArchi
Salut,
Un petit bout de code un peu plus long?
Parce que chez moi:
Code:

1 2 enum flag {TRUE,FALSE};
ça compile (même si je n'en vois pas trop l'intérêt).
18/02/2009, 11h25
white_tentacle

Suivant les en-têtes inclus (je pense notamment à windows.h), ça va être préprocessé en enum flag { 0, 1 }; et donc, marcher beaucoup moins bien...

Mais pourquoi ne pas utiliser tout simplement :

Code:

typedef bool flag;
18/02/2009, 11h41
coberle

Merci pour vos input.
@3D archi : j'ai une librairie de tools dans laquelle j'ai plusieurs classes qui utilise le fichiers Settings.h. La compilation de cette librairie ne pose pas de problème. Les messages d'erreur mentionnés ci-dessus apparaissent quand je compile un programme qui utilise cette libraire.
@white_tentacle : en fait, j'ai fait simple en posant la question mais en fait j'ai plusieurs valeurs (ERROR, NO_ERROR, WARNING, ...) et pas juste un booleen true/false

Christian
18/02/2009, 11h53
white_tentacle

En fait, l'erreur est quand même celle-là je pense.

Fais tourner uniquement le préprocesseur, et regarde le code généré. Tu dois avoir un entier dans ton énumération.

Citation:

Settings.h expected identifier before numeric constant
18/02/2009, 13h06
coberle

@white_tentacle : merci pour ton aide. A la suite de quoi, j'ai supprimé les énums et mis de entiers et cela ne donne plus d'erreur.
19/02/2009, 00h53
LittleWhite
Bonjour,

Je ne suis pas tout à fait d'accord avec la solution : enlever enum pour mettre des entiers. Les enums sont excellent pour le cas que tu cite, et cette solution c'est ce cacher du problème de base.
Certes je n'ai pas trouvé la solution :s , mais pour ma part je fais mes énums comme cela :
Code:

1 2 3 4 5 6 7 8 9 10 namespace Type { enum { NO_ERROR, ERROR, OTHER_TYPE }; }
Je ne sais plus si la possibilité de mettre un nom dans l'énum existe ( comme tu l'a fait )
19/02/2009, 09h06
white_tentacle

Surtout, ne pas mettre les enums en LETTRES_CAPITALES. C'est plutôt réservé pour les directives préprocesseurs.

Et là, c'est typiquement ce qui s'est passé, un clash entre une directive préprocesseur et la déclaration de l'enum.

D'ailleurs, la solution (repasser par des #define) est assez malheureuse, car la constante est désormais définie deux fois, probablement pas avec la même valeur, dans le programme.
20/02/2009, 00h34
LittleWhite

On clashe avec le préprocesseur même avec le namespace ( surement oui ... :s )
Zut, merci du conseil :)
20/02/2009, 09h05
3DArchi
Citation:

Envoyé par LittleWhite

On clashe avec le préprocesseur même avec le namespace ( surement oui ... :s )
Zut, merci du conseil :)

C'est un usage qui veut qu'on mette en majuscule les directives du préprocesseur :
Code:

1 2 3 4 #define MA_CONSTANTE 12 // qu'on préfère remplacer en C++ par : static const int ma_constante = 12;
21/02/2009, 01h19
LittleWhite

Peut t'on me dire l'usage d'écriture des enums, alors ?

J'ai tendance à les écrire comme ça :

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
namespace MyLib
{
  enum ErrorType
  {
    errNone = 0,
    errDiskFull,
    errDuplicateKey
  };
  enum State
  {
    stateNone = 0, // Si je n'avais pas préfixé, State::None aurait été en conflit avec ErrorType::None
    stateReady
  };
}

Salut,
Le fait est que tu choisi finalement très mal le nom de tes valeur énumérées:

True et false sont des mot clé définis, et il n'est pas exclu qu'il existe, dans un des fichier de la bibliothèque C, un #define FALSE 0 et un #define TRUE !FALSE, ce qui semble confirmé par le message d'erreur obtenu (un identifiant est attendu avant la constante numérique).

N'hésite pas à prévoir des noms réellement explicites pour tes valeur énumérées, telles que isTrue, isFalse, HasNoError, HasError,...

C'est, certes, plus long à écrire, mais cela permet d'atteindre le premier objectif de l'énumération qui est de fournir un nom explicite (à la lecture du code) à une valeur en vue de permettre au lecteur du code de comprendre ce que l'on teste (ou ce que l'on renvoie)
Citation:
Envoyé par LittleWhite
<snip>
Code:

1 2 3 4 5 6 7 8 9 10 namespace Type { enum { NO_ERROR, ERROR, OTHER_TYPE }; }
Je ne sais plus si la possibilité de mettre un nom dans l'énum existe ( comme tu l'a fait )
C'est tout à fait légal :D

La seule chose, c'est que tu perd le bénéfice du deuxième objectif de l'énumération, à savoir: regrouper les différentes valeurs énumérées au sein d'un seul et même type particulier...

En effet, lorsque tu crées une énumération sous la forme "classique" (en lui donnant un nom) de
Code:

1 2 3 4 5 6 enum eMyErrorType { meNoError, meErrorTypeOne, meErrorOtherType };
tu as la possibilité de déclarer une variable du type de l'énumération (ici, eMyErrorType).

Si tu règle correctement ton compilateur, et que tu écris un test à choix multiple sur la valeur de cette variable sous une forme qui pourrait se rapprocher de
Code:

1 2 3 4 5 6 7 8 9 10 11 12 eMyErrorType met; /* plus loin */ switch (met) { case meNoError: /*...*/ break; case meErrorTypeOne: /*...*/ break; /* le case meErrorOtherType est volontairement oublié */ };
le compilateur devrait t'indiquer que toutes les valeurs potentielles admise pour <met> n'ont pas été gérées.

De plus, si tu essaye de donner une valeur qui ne correspond à aucune des valeurs énumérées, le compilateur refusera la valeur indiquée.

Si tu ne donnes pas de nom à ton énumération, la seule utilité qu'elle garde, c'est de donner des identifiant uniques à différentes constantes numériques.

Si tu définis une énumération anonyme dans une portée globale ou dans un espace de noms, tu n'obtiens en définitive rien de bien plus utile que ce que tu peux obtenir avec un simple #define : l'identifiant de la valeur énumérée est remplacé par la valeur constante, mais ne représente aucun type auquel tu puisse faire appel et tu te trouve donc obligé de les manipuler comme s'il s'agissait d'un entier "quelconque":

Tu peux assigner la valeur à un entier avec un code proche de

Code:

int i = valeurEnumeree;

tu peux renvoyer la valeur énumérée lorsque la fonction doit renvoyer un entier (n'importe lequel: cela fonctionnerait si tu renvoyais un char, un short ou un long... en fonction du nombre de valeur énumérées dans l'énumération ;))
Code:

1 2 3 4 5 int foo() { /*...*/ return valeurEnumeree; }
Mais tu perd la possibilité de déclarer une variable du type précis de ton énumération (ce qui est normal vu qu'elle n'a pas de nom auquel faire référence) et, par la même, l'occasion de profiter de "l'intransigeance" du compilateur

Ceci dit, les énumérations anonymes ont un intérêt qu'il ne faut pas négliger, mais qui ne s'exprime réellement que dans le cadre d'énumérations imbriquées dans une classe ou une structure...

Ainsi, on peut envisager de l'utiliser pour représenter un état interne à la classe (ou à la structure) qui ne doit absolument pas être utiliser autrement que... de manière interne...

On peut aussi, et c'est souvent le cas, l'utiliser dans des classes template pour obtenir une information de valeur, sous une forme qui pourrait être celle de
Code:

1 2 3 4 5 6 template <class T> struct SizedStruct { typedef T type; // le type enum {value = sizeof(type)}; // la valeur };
Dans de telle circonstances, il n'y a pas vraiment d'intérêt à disposer d'un type particulier pour l'énumération et nous n'utiliserons de toutes manière la valeur énumérée que comme... un entier ;)

Vous m'avez de nouveau incité à écrire un roman... J'espère qu'il sera utile pour la compréhension ;)

22/02/2009, 01h35
LittleWhite

Encore merci pour la réponse. Pardon d'incité à écrire des romans :s.
C'est juste que je cherche à toujours faire un code meilleur, sachant que j'utilise des choses que je ne connais pas toujours les implications...
Vraiment merci :)

Citation:

Envoyé par LittleWhite

Peut t'on me dire l'usage d'écriture des enums, alors ?

Là, j'ai vu différentes choses.
Soit comme NiamrorH :

Citation:

Envoyé par NiamorH

J'ai tendance à les écrire comme ça :

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
namespace MyLib
{
  enum ErrorType
  {
    errNone = 0,
    errDiskFull,
    errDuplicateKey
  };
  enum State
  {
    stateNone = 0, // Si je n'avais pas préfixé, State::None aurait été en conflit avec ErrorType::None
    stateReady
  };
}

Soit comme ça :

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
 
namespace MyLib
{
  enum E_ErrorType
  {
    E_err_none = 0,
    E_err_disk_full,
    E_err_duplicate_key
  };
  enum E_State
  {
    E_state_none = 0, 
    E_state_ready
  };
}

ou aussi :
Soit comme ça :

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
 
namespace MyLib
{
  enum E_ErrorType
  {
    Err_E_none = 0,
    Err_E_disk_full,
    Err_E_duplicate_key
  };
  enum E_State
  {
    State_E_none = 0, 
    State_E_ready
  };
}

Ou pire (ce qui aboutit au même genre de pb que présenté qu début du fil) :

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
 
namespace MyLib
{
  enum ErrorType
  {
    none = 0,
    disk_full,
    duplicate_key
  };
  enum E_State
  {
    snone = 0,
    ready
  };
}