Portabilite d'un typecast (unsigned int) sur un bitfield
3 réponses
Lea GRIS
Bonjour,
J'effectue des test en utilisant une table de vérités encodée dans un
tableau dans le but d'apporter une solution générique en remplacement de
conditions imbriquées. (Autre avantage : La matrice est re-définissable
à l'exécution.)
Il s'agit de mettre en correspondance les valeurs booléennes en entrée
contenues dans un champ de bits et de les combiner pour indexer l'action
ou la valeur résultante.
Cependant pour indexer le tableau de vérités, le champ de bit contenant
les valeurs booléennes doit être considéré comme valeur entière composée
de tous les bits du champ.
J'aimerais savoir si c'est une construction acceptable _et surtout
portable_ d'utiliser un "typecast (unsigned int)" sur un champ de bits.
Selon les architectures CPU/compilateur, cette redéfinition de type
"bitfiled" vers "unsigned int" restera-t'elle cohérente (petit indien,
grand indien) ?
/* Restitution du label correspondant à l'état d'entrée
* contenu dans le champ de bits flags
*/
const char *
do_test (issue_flags flags)
{
unsigned int state; /* état résultant */
/* flags étant de type champ de bits issue_flags,
* Il a besoin d'être considéré comme nombre entier
* pour servir d'index à la table de vérités.
*/
state = truths[(unsigned int)flags];
return (states_labels[state]);
}
-- Jean-Marc FAQ de fclc: http://www.isty-info.uvsq.fr/~rumeau/fclc Site de usenet-fr: http://www.usenet-fr.news.eu.org
Antoine Leca
En news:47947c46$0$880$, Lea GRIS va escriure:
J'aimerais savoir si c'est une construction acceptable _et surtout portable_ d'utiliser un "typecast (unsigned int)" sur un champ de bits.
Non.
Selon les architectures CPU/compilateur, cette redéfinition de type "bitfiled" vers "unsigned int" restera-t'elle cohérente (petit indien, grand indien) ?
Pas du tout. En plus de petit- ou grand-boutien pour les entiers, tu dois considérer la possibilité que les bits (et donc les champs de bits) soit numérotés de gauche à droite ou de droite à gauche (ce qui dépend du compilateur), et aussi de savoir si le remplissage au-delà des 4 bits que tu définis soit par la gauche ou par la droite (ce qui dépend souvent de l'architecture cible et des possibilités qu'elle offre, et donc de la vision qu'en a celui qui écrit le compilateur). Le tout devra être rangé dans un entier (de 16 ou de 32 bits ? ah non, de 64...)
Voici un extrait de code correspondant :
/* champ de 4 bits contenant les états booléens en entrée */ struct issue_flags { bool issue_ended : 1;
bool est C99 (ou C++). Si tu utilises un compilateur C90, en général on utilise typedef int bool; ou quelque chose du même genre; et il est alors possible que le compilateur interprète le tout comme la déclaration d'un champ de UN bit de type ENTIER (signé), donc pouvant contenir 0 ou... -1
Bref, en règle général si tu souhaites faire quelque chose de portable, il ne faut pas utiliser les champs de bits.
Tu auras un résultat largement plus portable et aussi lisible avec un truc du genre
et l'utilisation des opérateurs & (tester un indicateur), |= (le positionner), &= ~ (l'effacer) et ^= (l'inverser), ce qui revient à contrôler toi-même les opérations sur le champ de bits.
Antoine
En news:47947c46$0$880$ba4acef3@news.orange.fr, Lea GRIS va escriure:
J'aimerais savoir si c'est une construction acceptable _et surtout
portable_ d'utiliser un "typecast (unsigned int)" sur un champ de
bits.
Non.
Selon les architectures CPU/compilateur, cette redéfinition de type
"bitfiled" vers "unsigned int" restera-t'elle cohérente (petit indien,
grand indien) ?
Pas du tout.
En plus de petit- ou grand-boutien pour les entiers, tu dois considérer la
possibilité que les bits (et donc les champs de bits) soit numérotés de
gauche à droite ou de droite à gauche (ce qui dépend du compilateur), et
aussi de savoir si le remplissage au-delà des 4 bits que tu définis soit par
la gauche ou par la droite (ce qui dépend souvent de l'architecture cible et
des possibilités qu'elle offre, et donc de la vision qu'en a celui qui écrit
le compilateur).
Le tout devra être rangé dans un entier (de 16 ou de 32 bits ? ah non, de
64...)
Voici un extrait de code correspondant :
/* champ de 4 bits contenant les états booléens en entrée */
struct issue_flags
{
bool issue_ended : 1;
bool est C99 (ou C++). Si tu utilises un compilateur C90, en général on
utilise
typedef int bool;
ou quelque chose du même genre; et il est alors possible que le compilateur
interprète le tout comme la déclaration d'un champ de UN bit de type ENTIER
(signé), donc pouvant contenir 0 ou... -1
Bref, en règle général si tu souhaites faire quelque chose de portable, il
ne faut pas utiliser les champs de bits.
Tu auras un résultat largement plus portable et aussi lisible avec un truc
du genre
et l'utilisation des opérateurs & (tester un indicateur), |= (le
positionner), &= ~ (l'effacer) et ^= (l'inverser), ce qui revient à
contrôler toi-même les opérations sur le champ de bits.
J'aimerais savoir si c'est une construction acceptable _et surtout portable_ d'utiliser un "typecast (unsigned int)" sur un champ de bits.
Non.
Selon les architectures CPU/compilateur, cette redéfinition de type "bitfiled" vers "unsigned int" restera-t'elle cohérente (petit indien, grand indien) ?
Pas du tout. En plus de petit- ou grand-boutien pour les entiers, tu dois considérer la possibilité que les bits (et donc les champs de bits) soit numérotés de gauche à droite ou de droite à gauche (ce qui dépend du compilateur), et aussi de savoir si le remplissage au-delà des 4 bits que tu définis soit par la gauche ou par la droite (ce qui dépend souvent de l'architecture cible et des possibilités qu'elle offre, et donc de la vision qu'en a celui qui écrit le compilateur). Le tout devra être rangé dans un entier (de 16 ou de 32 bits ? ah non, de 64...)
Voici un extrait de code correspondant :
/* champ de 4 bits contenant les états booléens en entrée */ struct issue_flags { bool issue_ended : 1;
bool est C99 (ou C++). Si tu utilises un compilateur C90, en général on utilise typedef int bool; ou quelque chose du même genre; et il est alors possible que le compilateur interprète le tout comme la déclaration d'un champ de UN bit de type ENTIER (signé), donc pouvant contenir 0 ou... -1
Bref, en règle général si tu souhaites faire quelque chose de portable, il ne faut pas utiliser les champs de bits.
Tu auras un résultat largement plus portable et aussi lisible avec un truc du genre
et l'utilisation des opérateurs & (tester un indicateur), |= (le positionner), &= ~ (l'effacer) et ^= (l'inverser), ce qui revient à contrôler toi-même les opérations sur le champ de bits.
Antoine
Lea GRIS
Bref, en règle général si tu souhaites faire quelque chose de portable, il ne faut pas utiliser les champs de bits.
Tu auras un résultat largement plus portable et aussi lisible avec un truc du genre
et l'utilisation des opérateurs & (tester un indicateur), |= (le positionner), &= ~ (l'effacer) et ^= (l'inverser), ce qui revient à contrôler toi-même les opérations sur le champ de bits.
Merci Antoine pour l'explication claire et détaillée. Je vais étudier et utiliser tout ça avec mon code.
-- Léa Gris
Bref, en règle général si tu souhaites faire quelque chose de portable, il
ne faut pas utiliser les champs de bits.
Tu auras un résultat largement plus portable et aussi lisible avec un truc
du genre
et l'utilisation des opérateurs & (tester un indicateur), |= (le
positionner), &= ~ (l'effacer) et ^= (l'inverser), ce qui revient à
contrôler toi-même les opérations sur le champ de bits.
Merci Antoine pour l'explication claire et détaillée. Je vais étudier et
utiliser tout ça avec mon code.
et l'utilisation des opérateurs & (tester un indicateur), |= (le positionner), &= ~ (l'effacer) et ^= (l'inverser), ce qui revient à contrôler toi-même les opérations sur le champ de bits.
Merci Antoine pour l'explication claire et détaillée. Je vais étudier et utiliser tout ça avec mon code.
