(Pour le reste, il faut simplement savoir que les champs de
bits peuvent probablement simplifier les programmes qui
manipulent des bits, au détriment de faire un programme
vraiment portable.)
(Pour le reste, il faut simplement savoir que les champs de
bits peuvent probablement simplifier les programmes qui
manipulent des bits, au détriment de faire un programme
vraiment portable.)
(Pour le reste, il faut simplement savoir que les champs de
bits peuvent probablement simplifier les programmes qui
manipulent des bits, au détriment de faire un programme
vraiment portable.)
Dans le message 423c53f1$0$21961$, JamesMichel Michaud wrote:
Dans le message
42388f8b$0$15287$, Olivier
Merci pour vos réponses...
Donc si j'ai bien compris,
struct Machin
{
DWORD Truc : 6, Chose : 26;
};
Signifie que la structure Machin à une taille de DWORD, 4
octets, soit 32 bits et qu'elle est composée de Truc qui
fait 6 bits et Chose qui en fait 26 !!??
Non. Seulement que Truc aura au moins 6 bits utilisables et
Chose en aura au moins 24.
Non. Il est garanti que Truc a exactement 6 bits, et Chose 26.
Je ne suis pas certain que c'est ce que dit la norme (je viens
de relire la norme C, ça ne me semble pas aussi clair). Je
sais évidemment que c'est l'intention.
Je comprends surtout que ma phrase ne semble pas dire
exactement à quoi je pensais (et qui reste peut-être faux...).
Je voulais dire que le compilateur allouera au moins 6 bits
pour que Truc ait bien ses 6 bits utilisables, etc.
Dans la mésure que les types sont signés, évidemment, c'est
difficile pour un programme conforme de le savoir, mais s'il
sont unsigned, si Truc vaut 63, ++ Truc vaut 0. Garanti par
la norme.
Oui, je suis parfaitement d'accord.
Mais il me semble possible que les 6 bits de Truc ne soit ni
complètement à gauche ni complètement à droite de l'espace
alloué.
C'est là que je ne suis pas capable de confirmer en lisant la
norme... Dans mon esprit, si j'ai besoin de manipuler 6 bits
dans quelque chose, je vais le faire avec des décalages et des
masques, car je suis sous l'impression que les champs de bits
ne me garantissent rien. Peut-être que je me trompe, c'est une
vieille idée que j'ai en tête (et comme je ne fais plus
beaucoup de manipulations de bits, elle ne m'a jamais vraiment
dérangée :-)
Il n'y aucune garantie en ce concerne la taille de Machin,
mais l'intention est clairement précisée que si la taille
d'un DWORD est 32 bits ou plus, que et Truc et Chose se
trouvent dans le même DWORD.
Oui, on est d'accord sur l'intention. Par contre, sur une
machine bizarre, je crois que le compilateur pourrait allouer
beaucoup plus, par exemple deux mots de 32 bits.
Dans le message 423c53f1$0$21961$626a14ce@news.free.fr, James
Michel Michaud wrote:
Dans le message
42388f8b$0$15287$7a628cd7@news.club-internet.fr, Olivier
Merci pour vos réponses...
Donc si j'ai bien compris,
struct Machin
{
DWORD Truc : 6, Chose : 26;
};
Signifie que la structure Machin à une taille de DWORD, 4
octets, soit 32 bits et qu'elle est composée de Truc qui
fait 6 bits et Chose qui en fait 26 !!??
Non. Seulement que Truc aura au moins 6 bits utilisables et
Chose en aura au moins 24.
Non. Il est garanti que Truc a exactement 6 bits, et Chose 26.
Je ne suis pas certain que c'est ce que dit la norme (je viens
de relire la norme C, ça ne me semble pas aussi clair). Je
sais évidemment que c'est l'intention.
Je comprends surtout que ma phrase ne semble pas dire
exactement à quoi je pensais (et qui reste peut-être faux...).
Je voulais dire que le compilateur allouera au moins 6 bits
pour que Truc ait bien ses 6 bits utilisables, etc.
Dans la mésure que les types sont signés, évidemment, c'est
difficile pour un programme conforme de le savoir, mais s'il
sont unsigned, si Truc vaut 63, ++ Truc vaut 0. Garanti par
la norme.
Oui, je suis parfaitement d'accord.
Mais il me semble possible que les 6 bits de Truc ne soit ni
complètement à gauche ni complètement à droite de l'espace
alloué.
C'est là que je ne suis pas capable de confirmer en lisant la
norme... Dans mon esprit, si j'ai besoin de manipuler 6 bits
dans quelque chose, je vais le faire avec des décalages et des
masques, car je suis sous l'impression que les champs de bits
ne me garantissent rien. Peut-être que je me trompe, c'est une
vieille idée que j'ai en tête (et comme je ne fais plus
beaucoup de manipulations de bits, elle ne m'a jamais vraiment
dérangée :-)
Il n'y aucune garantie en ce concerne la taille de Machin,
mais l'intention est clairement précisée que si la taille
d'un DWORD est 32 bits ou plus, que et Truc et Chose se
trouvent dans le même DWORD.
Oui, on est d'accord sur l'intention. Par contre, sur une
machine bizarre, je crois que le compilateur pourrait allouer
beaucoup plus, par exemple deux mots de 32 bits.
Dans le message 423c53f1$0$21961$, JamesMichel Michaud wrote:
Dans le message
42388f8b$0$15287$, Olivier
Merci pour vos réponses...
Donc si j'ai bien compris,
struct Machin
{
DWORD Truc : 6, Chose : 26;
};
Signifie que la structure Machin à une taille de DWORD, 4
octets, soit 32 bits et qu'elle est composée de Truc qui
fait 6 bits et Chose qui en fait 26 !!??
Non. Seulement que Truc aura au moins 6 bits utilisables et
Chose en aura au moins 24.
Non. Il est garanti que Truc a exactement 6 bits, et Chose 26.
Je ne suis pas certain que c'est ce que dit la norme (je viens
de relire la norme C, ça ne me semble pas aussi clair). Je
sais évidemment que c'est l'intention.
Je comprends surtout que ma phrase ne semble pas dire
exactement à quoi je pensais (et qui reste peut-être faux...).
Je voulais dire que le compilateur allouera au moins 6 bits
pour que Truc ait bien ses 6 bits utilisables, etc.
Dans la mésure que les types sont signés, évidemment, c'est
difficile pour un programme conforme de le savoir, mais s'il
sont unsigned, si Truc vaut 63, ++ Truc vaut 0. Garanti par
la norme.
Oui, je suis parfaitement d'accord.
Mais il me semble possible que les 6 bits de Truc ne soit ni
complètement à gauche ni complètement à droite de l'espace
alloué.
C'est là que je ne suis pas capable de confirmer en lisant la
norme... Dans mon esprit, si j'ai besoin de manipuler 6 bits
dans quelque chose, je vais le faire avec des décalages et des
masques, car je suis sous l'impression que les champs de bits
ne me garantissent rien. Peut-être que je me trompe, c'est une
vieille idée que j'ai en tête (et comme je ne fais plus
beaucoup de manipulations de bits, elle ne m'a jamais vraiment
dérangée :-)
Il n'y aucune garantie en ce concerne la taille de Machin,
mais l'intention est clairement précisée que si la taille
d'un DWORD est 32 bits ou plus, que et Truc et Chose se
trouvent dans le même DWORD.
Oui, on est d'accord sur l'intention. Par contre, sur une
machine bizarre, je crois que le compilateur pourrait allouer
beaucoup plus, par exemple deux mots de 32 bits.
Et j'y reviens : où est le problème de portabilité ?
Et j'y reviens : où est le problème de portabilité ?
Et j'y reviens : où est le problème de portabilité ?
Michel Michaud wrote:(Pour le reste, il faut simplement savoir que les champs de
bits peuvent probablement simplifier les programmes qui
manipulent des bits, au détriment de faire un programme
vraiment portable.)
Et j'y reviens : où est le problème de portabilité ? Je ne vois
rien qui rendrait un champs de bits moins portable que n'importe
quel type classique, disons int.
Michel Michaud wrote:
(Pour le reste, il faut simplement savoir que les champs de
bits peuvent probablement simplifier les programmes qui
manipulent des bits, au détriment de faire un programme
vraiment portable.)
Et j'y reviens : où est le problème de portabilité ? Je ne vois
rien qui rendrait un champs de bits moins portable que n'importe
quel type classique, disons int.
Michel Michaud wrote:(Pour le reste, il faut simplement savoir que les champs de
bits peuvent probablement simplifier les programmes qui
manipulent des bits, au détriment de faire un programme
vraiment portable.)
Et j'y reviens : où est le problème de portabilité ? Je ne vois
rien qui rendrait un champs de bits moins portable que n'importe
quel type classique, disons int.
Michel Michaud wrote:Oui, je suis parfaitement d'accord.
Et alors ?
Mais il me semble possible que les 6 bits de Truc ne soit ni
complètement à gauche ni complètement à droite de l'espace
alloué.
Et alors ? L'implémentation peut mettre des bits « don't care »
au milieu d'un int, aussi, sans que ce soit un champs de bits.
En quoi est-ce que les champs de bits sont différents.
Certainement. Et alors ? Sur au moins une machine encore vendue,
les int ont 36 bits, et non 32. Où est le problème ?
Michel Michaud wrote:
Oui, je suis parfaitement d'accord.
Et alors ?
Mais il me semble possible que les 6 bits de Truc ne soit ni
complètement à gauche ni complètement à droite de l'espace
alloué.
Et alors ? L'implémentation peut mettre des bits « don't care »
au milieu d'un int, aussi, sans que ce soit un champs de bits.
En quoi est-ce que les champs de bits sont différents.
Certainement. Et alors ? Sur au moins une machine encore vendue,
les int ont 36 bits, et non 32. Où est le problème ?
Michel Michaud wrote:Oui, je suis parfaitement d'accord.
Et alors ?
Mais il me semble possible que les 6 bits de Truc ne soit ni
complètement à gauche ni complètement à droite de l'espace
alloué.
Et alors ? L'implémentation peut mettre des bits « don't care »
au milieu d'un int, aussi, sans que ce soit un champs de bits.
En quoi est-ce que les champs de bits sont différents.
Certainement. Et alors ? Sur au moins une machine encore vendue,
les int ont 36 bits, et non 32. Où est le problème ?
Quand Michel écrivait "les champs de bits peuvent probablement
simplifier les programmes qui manipulent des bits", il est possible
qu'il ait pensé à la même chose que moi :
union
{
unsigned int machin;
struct truc
{
unsigned int bidule: 3;
unsigned int trucmuche: 29;
};
};
pour accéder "facilement" aux trois premiers bits d'un entier, sans
utiliser les opérateurs de bricolage de bits ( >>, &, ...)
Quand Michel écrivait "les champs de bits peuvent probablement
simplifier les programmes qui manipulent des bits", il est possible
qu'il ait pensé à la même chose que moi :
union
{
unsigned int machin;
struct truc
{
unsigned int bidule: 3;
unsigned int trucmuche: 29;
};
};
pour accéder "facilement" aux trois premiers bits d'un entier, sans
utiliser les opérateurs de bricolage de bits ( >>, &, ...)
Quand Michel écrivait "les champs de bits peuvent probablement
simplifier les programmes qui manipulent des bits", il est possible
qu'il ait pensé à la même chose que moi :
union
{
unsigned int machin;
struct truc
{
unsigned int bidule: 3;
unsigned int trucmuche: 29;
};
};
pour accéder "facilement" aux trois premiers bits d'un entier, sans
utiliser les opérateurs de bricolage de bits ( >>, &, ...)
On Sun, 20 Mar 2005 23:39:08 +0100, James Kanze :Et j'y reviens : où est le problème de portabilité ?
Quand Michel écrivait "les champs de bits peuvent probablement
simplifier les programmes qui manipulent des bits", il est
possible qu'il ait pensé à la même chose que moi :
union
{
unsigned int machin;
struct truc
{
unsigned int bidule: 3;
unsigned int trucmuche: 29;
};
};
pour accéder "facilement" aux trois premiers bits d'un entier,
sans utiliser les opérateurs de bricolage de bits ( >>, &,
...)
On Sun, 20 Mar 2005 23:39:08 +0100, James Kanze <kanze@none>:
Et j'y reviens : où est le problème de portabilité ?
Quand Michel écrivait "les champs de bits peuvent probablement
simplifier les programmes qui manipulent des bits", il est
possible qu'il ait pensé à la même chose que moi :
union
{
unsigned int machin;
struct truc
{
unsigned int bidule: 3;
unsigned int trucmuche: 29;
};
};
pour accéder "facilement" aux trois premiers bits d'un entier,
sans utiliser les opérateurs de bricolage de bits ( >>, &,
...)
On Sun, 20 Mar 2005 23:39:08 +0100, James Kanze :Et j'y reviens : où est le problème de portabilité ?
Quand Michel écrivait "les champs de bits peuvent probablement
simplifier les programmes qui manipulent des bits", il est
possible qu'il ait pensé à la même chose que moi :
union
{
unsigned int machin;
struct truc
{
unsigned int bidule: 3;
unsigned int trucmuche: 29;
};
};
pour accéder "facilement" aux trois premiers bits d'un entier,
sans utiliser les opérateurs de bricolage de bits ( >>, &,
...)
Dans le message 423dfb7b$0$21880$,Michel Michaud wrote:(Pour le reste, il faut simplement savoir que les champs de
bits peuvent probablement simplifier les programmes qui
manipulent des bits, au détriment de faire un programme
vraiment portable.)
Et j'y reviens : où est le problème de portabilité ? Je ne
vois rien qui rendrait un champs de bits moins portable que
n'importe quel type classique, disons int.
Pour faire de la manipulation de bits ? Vraiment on ne sait
rien sur les int à ce point ? Par exemple, ne peut-on pas
supposer, par exemple, que ((i & 1) == 0) nous dira si un
nombre est pair ?
Dans le message 423dfb7b$0$21880$626a14ce@news.free.fr,
Michel Michaud wrote:
(Pour le reste, il faut simplement savoir que les champs de
bits peuvent probablement simplifier les programmes qui
manipulent des bits, au détriment de faire un programme
vraiment portable.)
Et j'y reviens : où est le problème de portabilité ? Je ne
vois rien qui rendrait un champs de bits moins portable que
n'importe quel type classique, disons int.
Pour faire de la manipulation de bits ? Vraiment on ne sait
rien sur les int à ce point ? Par exemple, ne peut-on pas
supposer, par exemple, que ((i & 1) == 0) nous dira si un
nombre est pair ?
Dans le message 423dfb7b$0$21880$,Michel Michaud wrote:(Pour le reste, il faut simplement savoir que les champs de
bits peuvent probablement simplifier les programmes qui
manipulent des bits, au détriment de faire un programme
vraiment portable.)
Et j'y reviens : où est le problème de portabilité ? Je ne
vois rien qui rendrait un champs de bits moins portable que
n'importe quel type classique, disons int.
Pour faire de la manipulation de bits ? Vraiment on ne sait
rien sur les int à ce point ? Par exemple, ne peut-on pas
supposer, par exemple, que ((i & 1) == 0) nous dira si un
nombre est pair ?
Dans le message 423dfd5c$0$29138$,Michel Michaud wrote:Oui, je suis parfaitement d'accord.
Et alors ?
Et alors tu devrais être content, c'est tout.Mais il me semble possible que les 6 bits de Truc ne soit
ni complètement à gauche ni complètement à droite de
l'espace alloué.
Et alors ? L'implémentation peut mettre des bits « don't
care » au milieu d'un int, aussi, sans que ce soit un champs
de bits. En quoi est-ce que les champs de bits sont
différents.
C'est un point de vue intéressant.
Disons que j'ai toujours pensé que les probabilités étaient
meilleures au niveau de la simple représentation des types de
base. Mais tu as sûrement raison. Dès que j'ai l'occasion de
faire de la manipulation de bits, je tâcherai d'y repenser...
[...]Certainement. Et alors ? Sur au moins une machine encore
vendue, les int ont 36 bits, et non 32. Où est le problème ?
Il n'y a pas de problème James. À part le fait que tu sembles
t'énerver un peu, ce qui ne te ressemble pas :-)
Dans le message 423dfd5c$0$29138$626a14ce@news.free.fr,
Michel Michaud wrote:
Oui, je suis parfaitement d'accord.
Et alors ?
Et alors tu devrais être content, c'est tout.
Mais il me semble possible que les 6 bits de Truc ne soit
ni complètement à gauche ni complètement à droite de
l'espace alloué.
Et alors ? L'implémentation peut mettre des bits « don't
care » au milieu d'un int, aussi, sans que ce soit un champs
de bits. En quoi est-ce que les champs de bits sont
différents.
C'est un point de vue intéressant.
Disons que j'ai toujours pensé que les probabilités étaient
meilleures au niveau de la simple représentation des types de
base. Mais tu as sûrement raison. Dès que j'ai l'occasion de
faire de la manipulation de bits, je tâcherai d'y repenser...
[...]
Certainement. Et alors ? Sur au moins une machine encore
vendue, les int ont 36 bits, et non 32. Où est le problème ?
Il n'y a pas de problème James. À part le fait que tu sembles
t'énerver un peu, ce qui ne te ressemble pas :-)
Dans le message 423dfd5c$0$29138$,Michel Michaud wrote:Oui, je suis parfaitement d'accord.
Et alors ?
Et alors tu devrais être content, c'est tout.Mais il me semble possible que les 6 bits de Truc ne soit
ni complètement à gauche ni complètement à droite de
l'espace alloué.
Et alors ? L'implémentation peut mettre des bits « don't
care » au milieu d'un int, aussi, sans que ce soit un champs
de bits. En quoi est-ce que les champs de bits sont
différents.
C'est un point de vue intéressant.
Disons que j'ai toujours pensé que les probabilités étaient
meilleures au niveau de la simple représentation des types de
base. Mais tu as sûrement raison. Dès que j'ai l'occasion de
faire de la manipulation de bits, je tâcherai d'y repenser...
[...]Certainement. Et alors ? Sur au moins une machine encore
vendue, les int ont 36 bits, et non 32. Où est le problème ?
Il n'y a pas de problème James. À part le fait que tu sembles
t'énerver un peu, ce qui ne te ressemble pas :-)
