J'ai une question au sujet de l'arithm=E9tique enti=E8re.
Je sais que lorsque l'on d=E9passe la capacit=E9 d'un int, comme ceci par
exemple:
int n =3D INT_MAX + 1;
il s'agit d'un comportement ind=E9termin=E9 et on ne peut donc pas =EAtre
certains d'obtenir INT_MIN comme valeur. La m=EAme r=E9flexion vaudrait
pour un unsigned int.
Cependant, j'aimerais savoir ce qu'il en est pour les types entier
d'une taille inf=E9rieur =E0 celle d'un int. Par exemple, si j'utilise un
champ de bits non sign=E9 de trois bits. Est-ce que je suis garantit
que, si ce dernier vaut 7 et que je l'incr=E9mente, j'obtienne 0 ou
s'agit-il d'un comportement ind=E9termin=E9?
Merci infiniment pour vos réponses. Donc si je résume bien, les entiers non signés ont un comportement déterminé si on dépasse la valeur maximale de leur intervalle sauf s'il s'agit d'un champ de bits?
Merci infiniment pour vos réponses.
Donc si je résume bien, les entiers non signés ont un comportement
déterminé si on dépasse la valeur maximale de leur intervalle sauf
s'il s'agit d'un champ de bits?
Merci infiniment pour vos réponses. Donc si je résume bien, les entiers non signés ont un comportement déterminé si on dépasse la valeur maximale de leur intervalle sauf s'il s'agit d'un champ de bits?
Lucas Levrel
Le 21 juillet 2011, Tonton Th a écrit :
On 07/21/2011 03:30 PM, Antoine Leca wrote:
for (foo=0; foo<10; foo++) {
L'opération arithmétique d'incrémentation s'écrit
foo + 1
Boucle cosmétique, l'essentiel est entre les deux printf, et répond à la question traitée. Maintenant, il y a peut être 20 ans que ça marche par miracle ;)
En fait, Antoine n'a pas laissé la bonne ligne, mais sa remarque reste valable. Dans :
bf.field++;
il y a deux opérations : bf.field¿.field+1; l'addition 7+1, qui donne 8, et l'affectation de 8 à bf.field, qui donne 0.
-- LL
Le 21 juillet 2011, Tonton Th a écrit :
On 07/21/2011 03:30 PM, Antoine Leca wrote:
for (foo=0; foo<10; foo++) {
L'opération arithmétique d'incrémentation s'écrit
foo + 1
Boucle cosmétique, l'essentiel est entre les deux printf,
et répond à la question traitée. Maintenant, il y a peut
être 20 ans que ça marche par miracle ;)
En fait, Antoine n'a pas laissé la bonne ligne, mais sa remarque reste
valable. Dans :
bf.field++;
il y a deux opérations :
bf.field¿.field+1;
l'addition 7+1, qui donne 8, et l'affectation de 8 à bf.field, qui donne
0.
Boucle cosmétique, l'essentiel est entre les deux printf, et répond à la question traitée. Maintenant, il y a peut être 20 ans que ça marche par miracle ;)
En fait, Antoine n'a pas laissé la bonne ligne, mais sa remarque reste valable. Dans :
bf.field++;
il y a deux opérations : bf.field¿.field+1; l'addition 7+1, qui donne 8, et l'affectation de 8 à bf.field, qui donne 0.
-- LL
espie
In article , Taurre wrote:
Merci infiniment pour vos réponses. Donc si je résume bien, les entiers non signés ont un comportement déterminé si on dépasse la valeur maximale de leur intervalle sauf s'il s'agit d'un champ de bits?
Oui. Plus precisement, les champs de bits ont regulierement des petits soucis d'implementation qui font qu'il vaut mieux ne pas trop compter sur leur semantique precise...
alors que pour les entiers non signes, c'est etudie pour !
In article <b6390421-9c21-45c6-8861-a51ec9f9a726@e21g2000vbz.googlegroups.com>,
Taurre <jerome.frgacic@yahoo.fr> wrote:
Merci infiniment pour vos réponses.
Donc si je résume bien, les entiers non signés ont un comportement
déterminé si on dépasse la valeur maximale de leur intervalle sauf
s'il s'agit d'un champ de bits?
Oui. Plus precisement, les champs de bits ont regulierement des petits
soucis d'implementation qui font qu'il vaut mieux ne pas trop compter sur
leur semantique precise...
alors que pour les entiers non signes, c'est etudie pour !
Merci infiniment pour vos réponses. Donc si je résume bien, les entiers non signés ont un comportement déterminé si on dépasse la valeur maximale de leur intervalle sauf s'il s'agit d'un champ de bits?
Oui. Plus precisement, les champs de bits ont regulierement des petits soucis d'implementation qui font qu'il vaut mieux ne pas trop compter sur leur semantique precise...
alors que pour les entiers non signes, c'est etudie pour !
Tonton Th
On 07/22/2011 11:09 AM, Lucas Levrel wrote:
L'opération arithmétique d'incrémentation s'écrit
foo + 1
Boucle cosmétique, l'essentiel est entre les deux printf, et répond à la question traitée. Maintenant, il y a peut être 20 ans que ça marche par miracle ;)
En fait, Antoine n'a pas laissé la bonne ligne, mais sa remarque reste valable. Dans :
bf.field++;
il y a deux opérations : bf.field¿.field+1; l'addition 7+1, qui donne 8, et l'affectation de 8 à bf.field, qui donne 0.
Mais dans ce cas-là, pour moi, ce n'est plus une incrémentation, mais une addition. bf.field++ est différent de bar¿.field+1 puisque on sort du contexte du bitfield, et qu'il y a donc une promotion, non ?
--
Nous vivons dans un monde étrange/ http://foo.bar.quux.over-blog.com/
On 07/22/2011 11:09 AM, Lucas Levrel wrote:
L'opération arithmétique d'incrémentation s'écrit
foo + 1
Boucle cosmétique, l'essentiel est entre les deux printf,
et répond à la question traitée. Maintenant, il y a peut
être 20 ans que ça marche par miracle ;)
En fait, Antoine n'a pas laissé la bonne ligne, mais sa remarque reste
valable. Dans :
bf.field++;
il y a deux opérations :
bf.field¿.field+1;
l'addition 7+1, qui donne 8, et l'affectation de 8 à bf.field, qui donne 0.
Mais dans ce cas-là, pour moi, ce n'est plus une incrémentation,
mais une addition. bf.field++ est différent de bar¿.field+1
puisque on sort du contexte du bitfield, et qu'il y a donc une
promotion, non ?
--
Nous vivons dans un monde étrange/
http://foo.bar.quux.over-blog.com/
Boucle cosmétique, l'essentiel est entre les deux printf, et répond à la question traitée. Maintenant, il y a peut être 20 ans que ça marche par miracle ;)
En fait, Antoine n'a pas laissé la bonne ligne, mais sa remarque reste valable. Dans :
bf.field++;
il y a deux opérations : bf.field¿.field+1; l'addition 7+1, qui donne 8, et l'affectation de 8 à bf.field, qui donne 0.
Mais dans ce cas-là, pour moi, ce n'est plus une incrémentation, mais une addition. bf.field++ est différent de bar¿.field+1 puisque on sort du contexte du bitfield, et qu'il y a donc une promotion, non ?
--
Nous vivons dans un monde étrange/ http://foo.bar.quux.over-blog.com/
Antoine Leca
Tonton Th écrivit :
Mais dans ce cas-là, pour moi, ce n'est plus une incrémentation, mais une addition.
Ah! maintenant je comprend, tu parlais d'un autre langage C, le tien.
Dans la norme du langage, il est écrit (6.3.6 Additive operators) [#2:] [...] (Incrementing is equivalent to adding 1.)
Ou un peu avant (6.3.2.4 Postfix increment and decrement operators) [#2:] [...] After the result is obtained, the value of the operand is incremented. (That is, the value 1 of the appropriate type is added to it.) See the discussions of additive operators and compound assignment for [...]
Désolé pour la confusion, je n'avais pas compris.
bf.field++ est différent de bar¿.field+1 puisque on sort du contexte du bitfield, et qu'il y a donc une promotion, non ?
Non (enfin, pour moi, et dans le cadre de la machine abstraite). Il y a promotion pour le champ de bit, exactement comme il y a promotion pour un type entier d'ordre inférieur à int (en utilisant les notions de C99).
Évidemment, un compilateur est en droit d'optimiser cela à son goût ; par exemple pour un champ de taille 1, en utilisant XOR.
Antoine
Tonton Th écrivit :
Mais dans ce cas-là, pour moi, ce n'est plus une incrémentation,
mais une addition.
Ah! maintenant je comprend, tu parlais d'un autre langage C, le tien.
Dans la norme du langage, il est écrit (6.3.6 Additive operators)
[#2:] [...] (Incrementing is equivalent to adding 1.)
Ou un peu avant (6.3.2.4 Postfix increment and decrement operators)
[#2:] [...] After the result is obtained, the value of the
operand is incremented. (That is, the value 1 of the
appropriate type is added to it.) See the discussions of
additive operators and compound assignment for [...]
Désolé pour la confusion, je n'avais pas compris.
bf.field++ est différent de bar¿.field+1
puisque on sort du contexte du bitfield, et qu'il y a donc une
promotion, non ?
Non (enfin, pour moi, et dans le cadre de la machine abstraite).
Il y a promotion pour le champ de bit, exactement comme il y a promotion
pour un type entier d'ordre inférieur à int (en utilisant les notions de
C99).
Évidemment, un compilateur est en droit d'optimiser cela à son goût ;
par exemple pour un champ de taille 1, en utilisant XOR.
Mais dans ce cas-là, pour moi, ce n'est plus une incrémentation, mais une addition.
Ah! maintenant je comprend, tu parlais d'un autre langage C, le tien.
Dans la norme du langage, il est écrit (6.3.6 Additive operators) [#2:] [...] (Incrementing is equivalent to adding 1.)
Ou un peu avant (6.3.2.4 Postfix increment and decrement operators) [#2:] [...] After the result is obtained, the value of the operand is incremented. (That is, the value 1 of the appropriate type is added to it.) See the discussions of additive operators and compound assignment for [...]
Désolé pour la confusion, je n'avais pas compris.
bf.field++ est différent de bar¿.field+1 puisque on sort du contexte du bitfield, et qu'il y a donc une promotion, non ?
Non (enfin, pour moi, et dans le cadre de la machine abstraite). Il y a promotion pour le champ de bit, exactement comme il y a promotion pour un type entier d'ordre inférieur à int (en utilisant les notions de C99).
Évidemment, un compilateur est en droit d'optimiser cela à son goût ; par exemple pour un champ de taille 1, en utilisant XOR.
Antoine
Antoine Leca
Taurre écrivit :
Merci infiniment pour vos réponses. Donc si je résume bien, les entiers non signés ont un comportement déterminé si on dépasse la valeur maximale de leur intervalle sauf s'il s'agit d'un champ de bits?
Je n'écrirais pas cela. Mais la remarque de Marc est plus juste que d'éventuelles précisions sur ce que devrait faire les compilateurs : si tu cherches à écrire des programmes portables tout en privilégiant la compacité, il vaut mieux éviter les champs de bits et écrire le code équivalent avec des opérations binaires (&, |, ^) et des masques.
Antoine
Taurre écrivit :
Merci infiniment pour vos réponses.
Donc si je résume bien, les entiers non signés ont un comportement
déterminé si on dépasse la valeur maximale de leur intervalle sauf
s'il s'agit d'un champ de bits?
Je n'écrirais pas cela. Mais la remarque de Marc est plus juste que
d'éventuelles précisions sur ce que devrait faire les compilateurs : si
tu cherches à écrire des programmes portables tout en privilégiant la
compacité, il vaut mieux éviter les champs de bits et écrire le code
équivalent avec des opérations binaires (&, |, ^) et des masques.
Merci infiniment pour vos réponses. Donc si je résume bien, les entiers non signés ont un comportement déterminé si on dépasse la valeur maximale de leur intervalle sauf s'il s'agit d'un champ de bits?
Je n'écrirais pas cela. Mais la remarque de Marc est plus juste que d'éventuelles précisions sur ce que devrait faire les compilateurs : si tu cherches à écrire des programmes portables tout en privilégiant la compacité, il vaut mieux éviter les champs de bits et écrire le code équivalent avec des opérations binaires (&, |, ^) et des masques.
