Discussion :

[hibou107]

Bonjour,
Je suis en train de lire le code source d'un programme, et j'ai trouvé

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
enum {
// INCLUDE/mrv/AdMask.h:
// please repect following mask according to the type
 
 
    ATTR_MASK_INT16     = 0x1000, /* Property flag : INT16 not used in fact */

C'est pour moi un peu bizarre avec 0X1000, c'est quoi ce type et ça sert à quoi d'énumérer les types comme ça?

Merci

[koala01]

Salut,

La présence de 0x indique au compilateur qu'il doit prendre la valeur sous sa forme hexadécimale, ce qui correspond à la valeur (décimale) de 4096 à la valeur binaire de 1000000000000 (2^12).

L'idée est de fournrir une valeur explicite pour la valeur énumérée.

Comme il s'agit d'un masque binaire (comprend: chaque bit de l'énumération représente un flag particulier, non exhaustif) il est souvent plus facile de représenter les valeurs sous forme binaire (ou hexadécimale) que sous forme décimale, car la conversion est plus simple

[hibou107]

Merci pour ta réponse

[Steinvikel]

Bonjour, j'en profite pour réactiver cette discussion.
Dans les cours de C++, il est décrit qu'une valeur peut être écrite en base 16, 10, 8 (hexadécimal, décimal, octal) ou sous forme de caractère.

Etant issue du domaine de l'électronique je me demande alors:
La norme prévoit-elle l'emploi d'un préfixe pour la forme binaire ?
... au même titre que 0... ou 0x...
pourquoi pas 0b... comme le font certains programmes (ex: mikroC for PIC)

PS: cette forme binaire est indispensable pour donner du sens à la lecture, lorsque l'on travail sur les flag, registre, ou toute valeur dépendant de l'emplacement des bits.

[koala01]

Bonjour, j'en profite pour réactiver cette discussion.
Dans les cours de C++, il est décrit qu'une valeur peut être écrite en base 16, 10, 8 (hexadécimal, décimal, octal) ou sous forme de caractère.

Etant issue du domaine de l'électronique je me demande alors:
La norme prévoit-elle l'emploi d'un préfixe pour la forme binaire ?
... au même titre que 0... ou 0x...
pourquoi pas 0b... comme le font certains programmes (ex: mikroC for PIC)

La réponse est simple : non, la norme ne prévoit rien pour indiquer une écriture binaire.

A vrai dire, cela va même plus loin : il n'y a, à par la possibilité d'avoir une écriture sous la forme des termes true et false, aucune fonction directe permettant de représenter des valeurs binaires.

Si tu veux l'affichage d'une valeur binaire, tu dois jouer avec des conteneurs spécifiques comme std::bitset (ou boost::dynamic_bitset) qui exposent une fonction susceptible de générer une chaîne de caractères au format binaire.

PS: cette forme binaire est indispensable pour donner du sens à la lecture, lorsque l'on travail sur les flag, registre, ou toute valeur dépendant de l'emplacement des bits.

D'un point de vue purement électronique, cela se conçoit sans peine. D'un point de vue purement conceptuel pour la programmation, je subodore que c'est pour orienter les développeurs vers ce qui serait considéré comme une "bonne pratique" : créer une énumération qui reprenne les différentes valeurs pour les flags.

En simplifiant vraiment beaucoup, on peut considérer qu'il existe deux possibilités de définir une valeur qui ne prend qu'un bit à 1:

• En retenant la valeur correspondante de chaque bit (1, 2, 4, 8, 16, 32, 64, ...), ce qui n'est quand même pas tellement évident ou
• en utilisant le décalage de bits : 1<<0 == 1, 1<<1 == 2, 1<<2 == 4, 1<<3==16, ..., ce qui est déjà plus facile, vu qu'il suffit de connaître le "numéro d'ordre" du bit que l'on veut mettre à 1

(il y a peut être d'autres solutions, mais ce sont en tout état de cause les plus utilisées )

D'un autre coté, on dispose de toutes manières des opérateurs binaire AND et OR, qui nous permettent de vérifier / définir des flags multiples : 1<<0 |1<<2 vaudra 5 (101 en binaire); FLAGS & N vaudra N si les bits correspondant à la valeur N sont à 1 dans FLAGS.

Et il ne faut surtout pas oublier que les flags ont systématiquement une signification qui est propre à la mise à 1 du bit correspondant, par exemple, les flags correspondant au formatage d'un texte pour les flux formaté (tels que cout, cin, ifstream ou ofstream) ont (chez moi en tout cas) les valeurs suivante:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
 
      boolalpha 	= 1L << 0,  // ==1
      dec 		= 1L << 1,  // ==2
      fixed 		= 1L << 2,  // ==4
      hex 		= 1L << 3,  // ==8
      internal          = 1L << 4,  // ==16
      left 		= 1L << 5,  // ==32
      oct 		= 1L << 6,  // ==64
      right 		= 1L << 7,  // ==128
      scientific 	= 1L << 8,  // ==256
      showbase  	= 1L << 9,  // ==512
      showpoint  	= 1L << 10,  // ==1024
      showpos    	= 1L << 11,  // ==2048
      skipws        	= 1L << 12,  // ==4096
      unitbuf        	= 1L << 13,  // ==8192
      uppercase 	= 1L << 14,  // ==16384
      adjustfield 	= left | right | internal,   // == 32+128 + 16
      basefield 	= dec | oct | hex,         // ==  2 + 8 + 64
      floatfield 	= scientific | fixed,    // == 256 + 4

(adaptation du flag _Ios_Fmtflags que l'on trouve classiquement dans ios_base.h auxquels j'ai juste ajouté la correspondance en valeur décimale )

Mon intuition (qui ne demande qu'à être démentie ) est que la norme tend à inciter les développeurs à définir des termes représentant les différents tags qu'ils utilisent, quelle que soit la forme qu'il prennent, en ne fournissant aucun moyen de définir une valeur sous la forme binaire.

Il est en effet plus facile de comprendre ce que vaut un flag qui correspond à FLAG1 | FLAG3 | FLAG64 que de comprendre le même flag qui serait égal à 1<<1 + 1<<3 +1<<64. D'un point de vue binaire, la représentation est strictement identique, mais, en évitant les "constantes magiques", on gagne en facilité de compréhension Et il en va bien sûr de même lorsqu'il s'agit dévaluer si un bit est à 1 ou non (ou, si tu préfères, si un flag est activé ou non) .

Après, la forme que prendra la définition des différents flag est laissée à la libre appréciation du développeur. On peut envisager trois solution pour ce faire:
en utilisant la directive préprocesseur #define:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
#define ONE 1<<0
#define TWO 1<<1
/* ... */
#define N 1<<N-1

En ayant recours au constantes statiques

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
static const int one = 1<<0;
static const int two = 1<<1;
/* ... */
static const int N = 1<<N-1;

Ou enfin en ayant recours aux énumérations (hein quoi qui a parlé d'énumération fortement typées en C++11 )

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
enum /*class */ myEnum{
    one = 1<<0,
    two = 1<<1,
    /* ... */
    n = 1<<n-1
};

A titre personnel, je préfères les énumérations en premier recours, puis les constantes statiques. Mais je garde mon argumentaire sur le sujet pour plus tard, s'il t'intéresse

[Steinvikel]

merci pour cette réactivité, et surtout cette précision

Ainsi donc, c'est impossible sans bliliothèque...
Je te suis dans la représentation de chaque flag indépendamment dans la syntaxe. Mais je garde tout de même à l'esprit que chaque domaine a ses avantages et ses inconvénients à l'usage d'une forme ou d'une autre.

Plus on sera proche du hardware, et plus on aura l'usage de valeurs sous forme de motif (correspondant à l'architecture physique >> électronique), et plus on sera proche du software et plus les valeurs seront abstraites (où la syntaxe apporte tout leur sens).

Donc si j'ai bien compris, pas d'autre choix que d'écrire quelques lignes supplémentaires avec l'usage de masque ET et OU.
PS: par expérience de mes débuts, je proscrit l'usage du décalage si se n'est pas dans le but de décaler ^^' (on a vite fait d'expulser 1bit en dehors sens être averti)

Concernant les énumération, j'ai écrit un post, car je cale sur certaines frontières.
si le coeur t'en dit... =)

Savoir pourquoi tu as une préférence pour une enum à plusieurs constantes m'intéresse effectivement, mais je ne sais pas s'il on devrait poursuivre dans cette discussion ou en ouvrir une nouvelle. Dans tout le cas, il me faudra trouver des réponses sur les énumérations pour pouvoir en discuter avec toi.