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
  };
}