Discussion :

[Franck.H]

Bonjour,

j'ai vu que parfois dans certains headers que pour certaines constantes, au lieu de l'attribution directe d'une valeure entière on trouve parfois des décallages de bits sur une meme valeur.

Exemple:

Code :

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

1
2
3
4
5
6
typedef enum
{
   EX_UN = 1 << 1,
   EX_DEUX = 1 << 2,
   EX_TROIS = 1 << 3
}test_e;

Pourquoi ? Y'a t-il un avantage ? Ou bien .... chais pas ... !
Ceci est surtout par curiosité et pour ne pas rester idiot devant de telles constantes

En tout cas, merci d'avance pour vos lumières

[Mac LAK]

La lisibilité, uniquement... Pour le compilateur, écrire "1<<24", "0x1000000" ou "16777216", c'est du pareil au même : c'est une constante, il n'y a pas d'opération effectuée à l'exécution.

Simplement, il est plus facile de voir que l'on positionne le 25ème bit (base zéro, ne l'oublions pas !) d'un mot avec "1<<24", que de devoir "décoder" le chiffre décimal.

C'est encore plus visible sur des combinaisons : combien de bits sont positionnés (et lesquels !) avec la constante "2147516417" ? Plus facile de le voir si c'est écrit "(1<<0) | (1<<31) | (1<<15)", non ? ;-)

En plus, ça permet de vérifier très rapidement si l'on n'a pas de conflits entre les valeurs (deux identiques), et qu'elles sont bel et bien séparables et que l'on peut donc les combiner par OR binaire.

En général, ce genre de construction est principalement utilisée pour l'accès aux registres d'un contrôleur (développement de drivers ou informatique embarquée principalement), pour les protocoles de communication et pour des constantes dont la signification est liée aux différents bits la composant (type "bitfield").

[Franck.H]

Ok ! Donc dans le cas d'un developpement de ce qui a de plus normal par ex une fonction prenant en parametre une enumération de constantes de ce type n'as pas vraiment d'incidance que ce soit dans ce format:

Code :

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

1
2
3
4
5
6
typedef enum
{
   EX_UN = 1 << 1,
   EX_DEUX = 1 << 2,
   EX_TROIS = 1 << 3
}test_e;

ou dans celui-ci

Code :

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

1
2
3
4
5
6
typedef enum
{
   EX_UN,
   EX_DEUX,
   EX_TROIS
}test_e;

: :

[Mac LAK]

Ok ! Donc dans le cas d'un developpement de ce qui a de plus normal

Oups, attention là, tu utilises un mot dangereux... C'est quoi, un développement "normal" ?
Pour moi, c'est de l'embarqué avec moult optimisations (parfois même vicelardes), des protocoles de communication au taquet et des accès incessants au matériel... Ou du Delphi sous WinXP... T'es sûr qu'on a la même définition de "normal" ?

par ex une fonction prenant en parametre une enumération de constantes de ce type n'as pas vraiment d'incidance que ce soit dans ce format:

C'est même bien pire que ça : en programmation de haut niveau, la valeur d'une énumération ne devrait avoir absolument aucune importance !

Le C (ou le C++) permettent des "familiarités" avec les énumérations, mais il faut voir qu'assigner une valeur à une énumération ne sert qu'à s'éviter de devoir faire deux fonctions de conversion : une "enum->int" et l'autre "int->enum", les deux n'étant que de monstrueux switchs... Dans un langage rigide comme l'ADA (ou même le Pascal !), tu peux toujours courir pour "numéroter" tes énumérations ! ;-)

Après, il faut bien voir ce qu'est le C à l'origine : un macro-assembleur, et non pas un "vrai" langage de haut niveau (et pas de trolls !!). Il a ses qualités, ses défauts, mais la rigidité n'est certainement pas une caractéristique du C... Il n'existe même pas d'instructions de type "Succ", "Pred", "High" et "Low" sur les énumérations C. Il est même possible d'assigner une valeur indéfinie à une variable énumérée, ou d'avoir des doublons dans une énumération...

Les énumérations numérotées ont cependant beaucoup d'applications :
- Mapping direct de codes de registres (commandes, codes d'erreurs, etc...) en énumération plus aisément manipulables que des #define au taquet.
- Séparation de codes d'erreurs en 3 composantes dans la même énumération : erreurs critiques (<0), cas nominal (==0), avertissement (>0).
- Pour des protocoles : garantie d'avoir les mêmes valeurs quel que soit le compilateur, la cible ou les évolutions/rajouts du protocole (nouvelles commandes, nouvelles erreurs, etc...).
- Etc...

Si tu programmes "façon haut niveau" en C, tu n'as normalement jamais besoin de numéroter les éléments de tes énumérations : j'aurais même tendance à dire qu'il y a potentiellement une grosse faille de conception si c'est malgré tout nécessaire.
Par contre, en bas niveau (et l'implémentation d'un protocole, c'est du bas niveau si l'on y réfléchit bien), c'est souvent crucial pour tenir des performances correctes ET conserver un code source lisible et maintenable.

Est-ce que ça répond à tes questions ?

[Franck.H]

Oui tout à fait, j'en aurais donc certainement jamais à utiliser des constantes de ce type ! Mais je rappel que c'etait juste à titre de curiosité étant donné que je ne suis pas trop familier avec ce genre là: décallage de bits. Etant donné que j'en ai jamais eu besoin

En tous cas merci, ca m'a aidé à savoir dans quels cas précis on peut et où il est souhaitable d'utiliser de telles manières ! Pour ma part en C je ne fait pour l'instant que du haut niveau étant avec un tit mélange GTK voir plus tard SDL mais je pense que ca s'arrêtera là

Encore merci

[Emmanuel Delahaye]

Bonjour,

j'ai vu que parfois dans certains headers que pour certaines constantes, au lieu de l'attribution directe d'une valeure entière on trouve parfois des décallages de bits sur une meme valeur.

Exemple:

Code :

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

1
2
3
4
5
6
typedef enum
{
   EX_UN = 1 << 1,
   EX_DEUX = 1 << 2,
   EX_TROIS = 1 << 3
}test_e;

Pourquoi ? Y'a t-il un avantage ? Ou bien .... chais pas ... !
Ceci est surtout par curiosité et pour ne pas rester idiot devant de telles constantes

En tout cas, merci d'avance pour vos lumières

Plusieurs remarques en plus de ce qui a été dit.
Un enum produit au maximum un int, soit un masque 1 << 14 garanti. On ne sait pas faire d'enum non signé ni d'enum de long.

Pour être portable, il faut faire ceci :

#define BIT(n) (1ul << (n))

avec ça, on garantit 32 bits (n de 0 à 31) (type unsigned long)

En c99, on peux faire :

#define BIT(n) (1ull << (n))

(type unsigned long long, avec n de 0 à 63)

[Cunixsvp]

Mac, quand tu disais que le C n'est pas robuste, c'est un doux eufémisme non ?

[Emmanuel Delahaye]

Mac, quand tu disais que le C n'est pas robuste, c'est un doux eufémisme non ?

Le problème ne vient pas du C, mais des programmeurs... Ce n'est pas un langage qui fait la robustesse d'une application, mais une organisation modulaire, le codage, les tests unitaires... tout celà n'a rien à voir avec le langage...

[Mac LAK]

tout celà n'a rien à voir avec le langage...

Bon, on va encore me traiter de trolleur, mais un langage qui permet d'assigner n'importe quoi à n'importe quelle variable, j'appelle pas ça de la robustesse... Un simple cast permet d'assigner un byte à un char* si on le désire !! Et je ne parle même pas de la vérification d'étendue ou des tests de débordement de tableaux. Le C n'est pas franchement le langage le plus sécurisé qui soit, mais il faut mettre à son crédit qu'il n'a pas été conçu dans ce but non plus.

Essaie d'assigner un entier strictement positif (1..n) à un entier positif ou nul (0..n) en ADA, tu verras ce que je veux dire par "rigide" : c'est l'erreur (pas un warning, mais bien une erreur !) de compilation direct. Pourtant, les domaines sont compatibles, mais les types sont différents => erreur sans appel. Et un simple transtypage n'est pas possible, il faudra redéfinir un opérateur d'affectation pour pouvoir faire une telle opération.

En C, pour faire un programme robuste, il faut souvent doubler la taille du code. Dans un langage rigide, c'est pour faire "sauter" les protections qu'il faut doubler la taille du code... Il y a un peu plus qu'une simple nuance.