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?
J'ai une question au sujet de l'arithmétique entière. Je sais que lorsque l'on dépasse la capacité d'un int, comme ceci par exemple:
int n = INT_MAX + 1;
il s'agit d'un comportement indéterminé et on ne peut donc pas être certains d'obtenir INT_MIN comme valeur. La même réflexion vaudrait pour un unsigned int.
Non. Les unsigned int ont un comportement determine. L'intervalle de valeur est defini par l'implementation, mais UINT_MAX+1 vaut 0.
Cependant, j'aimerais savoir ce qu'il en est pour les types entier d'une taille inférieur à celle d'un int. Par exemple, si j'utilise un champ de bits non signé de trois bits. Est-ce que je suis garantit que, si ce dernier vaut 7 et que je l'incrémente, j'obtienne 0 ou s'agit-il d'un comportement indéterminé?
Non, rien de plus garanti, voire encore moins que pour les entiers. Il est fortement deconseille d'utiliser des champs de bits pour avoir un comportement defini...
In article <1ac0dacd-4ced-49bd-a283-478f7a85dfcc@g16g2000yqg.googlegroups.com>,
Taurre <jerome.frgacic@yahoo.fr> wrote:
Bonjour à tous,
J'ai une question au sujet de l'arithmétique entière.
Je sais que lorsque l'on dépasse la capacité d'un int, comme ceci par
exemple:
int n = INT_MAX + 1;
il s'agit d'un comportement indéterminé et on ne peut donc pas être
certains d'obtenir INT_MIN comme valeur. La même réflexion vaudrait
pour un unsigned int.
Non. Les unsigned int ont un comportement determine. L'intervalle de valeur
est defini par l'implementation, mais UINT_MAX+1 vaut 0.
Cependant, j'aimerais savoir ce qu'il en est pour les types entier
d'une taille inférieur à celle d'un int. Par exemple, si j'utilise un
champ de bits non signé de trois bits. Est-ce que je suis garantit
que, si ce dernier vaut 7 et que je l'incrémente, j'obtienne 0 ou
s'agit-il d'un comportement indéterminé?
Non, rien de plus garanti, voire encore moins que pour les entiers. Il est
fortement deconseille d'utiliser des champs de bits pour avoir un comportement
defini...
J'ai une question au sujet de l'arithmétique entière. Je sais que lorsque l'on dépasse la capacité d'un int, comme ceci par exemple:
int n = INT_MAX + 1;
il s'agit d'un comportement indéterminé et on ne peut donc pas être certains d'obtenir INT_MIN comme valeur. La même réflexion vaudrait pour un unsigned int.
Non. Les unsigned int ont un comportement determine. L'intervalle de valeur est defini par l'implementation, mais UINT_MAX+1 vaut 0.
Cependant, j'aimerais savoir ce qu'il en est pour les types entier d'une taille inférieur à celle d'un int. Par exemple, si j'utilise un champ de bits non signé de trois bits. Est-ce que je suis garantit que, si ce dernier vaut 7 et que je l'incrémente, j'obtienne 0 ou s'agit-il d'un comportement indéterminé?
Non, rien de plus garanti, voire encore moins que pour les entiers. Il est fortement deconseille d'utiliser des champs de bits pour avoir un comportement defini...
Antoine Leca
Taurre écrivit :
J'ai une question au sujet de l'arithmétique entière. Je sais que lorsque l'on dépasse la capacité d'un int, comme ceci par exemple:
int n = INT_MAX + 1;
il s'agit d'un comportement indéterminé et on ne peut donc pas être certains d'obtenir INT_MIN comme valeur.
Clairement. Imagine par exemple le cas d'une machine en signe + magnitude, donc où le signe est dans le bit de poids fort ; si aucune précaution n'est prise au niveau matériel ou implémentation, INT_MAX+1 vaut... -0 !
La même réflexion vaudrait pour un unsigned int.
Mauvaise pioche. Les types entier non signés en C sont particuliers, ils implémentent l'arithmétique sur l'intervalle [0, UINT_MAX]; donc UINT_MAX+1 vaut 0, et (unsigned)INT_MAX + 1 vaut une valeur parfaitement définie par l'implémentation (qui peut être 0).
Cependant, j'aimerais savoir ce qu'il en est pour les types entier d'une taille inférieur à celle d'un int.
Comment fais-tu en C pour faire une opération arithmétique sur un entier de taille strictement inférieure à celle d'un int ?
Par exemple, si j'utilise un champ de bits non signé de trois bits. Est-ce que je suis garantit que, si ce dernier vaut 7 et que je l'incrémente, j'obtienne 0 ou s'agit-il d'un comportement indéterminé?
Ni l'un ni l'autre ; tu es sûr d'obtenir 8, ce qui me paraît éminemment raisonnable.
Maintenant, en dehors des considérations arithmétiques, si ta question est, quelle sera la valeur du champ de bits si on y stocke 8 ? la réponse est 0 parce qu'il est unsigned, en cohérence avec le point ci-dessus; si le champ était signed tu aurais un comportement indéfini; sinon, il faut regarder comment ton compilateur traite les champs int.
Antoine
Taurre écrivit :
J'ai une question au sujet de l'arithmétique entière.
Je sais que lorsque l'on dépasse la capacité d'un int, comme ceci par
exemple:
int n = INT_MAX + 1;
il s'agit d'un comportement indéterminé et on ne peut donc pas être
certains d'obtenir INT_MIN comme valeur.
Clairement. Imagine par exemple le cas d'une machine en signe +
magnitude, donc où le signe est dans le bit de poids fort ; si aucune
précaution n'est prise au niveau matériel ou implémentation, INT_MAX+1
vaut... -0 !
La même réflexion vaudrait pour un unsigned int.
Mauvaise pioche. Les types entier non signés en C sont particuliers, ils
implémentent l'arithmétique sur l'intervalle [0, UINT_MAX]; donc
UINT_MAX+1 vaut 0, et (unsigned)INT_MAX + 1 vaut une valeur parfaitement
définie par l'implémentation (qui peut être 0).
Cependant, j'aimerais savoir ce qu'il en est pour les types entier
d'une taille inférieur à celle d'un int.
Comment fais-tu en C pour faire une opération arithmétique sur un entier
de taille strictement inférieure à celle d'un int ?
Par exemple, si j'utilise un
champ de bits non signé de trois bits. Est-ce que je suis garantit
que, si ce dernier vaut 7 et que je l'incrémente, j'obtienne 0 ou
s'agit-il d'un comportement indéterminé?
Ni l'un ni l'autre ; tu es sûr d'obtenir 8, ce qui me paraît éminemment
raisonnable.
Maintenant, en dehors des considérations arithmétiques, si ta question
est, quelle sera la valeur du champ de bits si on y stocke 8 ? la
réponse est 0 parce qu'il est unsigned, en cohérence avec le point
ci-dessus; si le champ était signed tu aurais un comportement indéfini;
sinon, il faut regarder comment ton compilateur traite les champs int.
J'ai une question au sujet de l'arithmétique entière. Je sais que lorsque l'on dépasse la capacité d'un int, comme ceci par exemple:
int n = INT_MAX + 1;
il s'agit d'un comportement indéterminé et on ne peut donc pas être certains d'obtenir INT_MIN comme valeur.
Clairement. Imagine par exemple le cas d'une machine en signe + magnitude, donc où le signe est dans le bit de poids fort ; si aucune précaution n'est prise au niveau matériel ou implémentation, INT_MAX+1 vaut... -0 !
La même réflexion vaudrait pour un unsigned int.
Mauvaise pioche. Les types entier non signés en C sont particuliers, ils implémentent l'arithmétique sur l'intervalle [0, UINT_MAX]; donc UINT_MAX+1 vaut 0, et (unsigned)INT_MAX + 1 vaut une valeur parfaitement définie par l'implémentation (qui peut être 0).
Cependant, j'aimerais savoir ce qu'il en est pour les types entier d'une taille inférieur à celle d'un int.
Comment fais-tu en C pour faire une opération arithmétique sur un entier de taille strictement inférieure à celle d'un int ?
Par exemple, si j'utilise un champ de bits non signé de trois bits. Est-ce que je suis garantit que, si ce dernier vaut 7 et que je l'incrémente, j'obtienne 0 ou s'agit-il d'un comportement indéterminé?
Ni l'un ni l'autre ; tu es sûr d'obtenir 8, ce qui me paraît éminemment raisonnable.
Maintenant, en dehors des considérations arithmétiques, si ta question est, quelle sera la valeur du champ de bits si on y stocke 8 ? la réponse est 0 parce qu'il est unsigned, en cohérence avec le point ci-dessus; si le champ était signed tu aurais un comportement indéfini; sinon, il faut regarder comment ton compilateur traite les champs int.
Antoine
Pascal J. Bourguignon
Antoine Leca writes:
Taurre écrivit :
Cependant, j'aimerais savoir ce qu'il en est pour les types entier d'une taille inférieur à celle d'un int.
Comment fais-tu en C pour faire une opération arithmétique sur un entier de taille strictement inférieure à celle d'un int ?
Mais ce n'est qu'une optimisation, sémantiquement, c'est comme si on faisait l'opération sur un int.
Par exemple, si j'utilise un champ de bits non signé de trois bits. Est-ce que je suis garantit que, si ce dernier vaut 7 et que je l'incrémente, j'obtienne 0 ou s'agit-il d'un comportement indéterminé?
Ni l'un ni l'autre ; tu es sûr d'obtenir 8, ce qui me paraît éminemment raisonnable.
Maintenant, en dehors des considérations arithmétiques, si ta question est, quelle sera la valeur du champ de bits si on y stocke 8 ? la réponse est 0 parce qu'il est unsigned, en cohérence avec le point ci-dessus; si le champ était signed tu aurais un comportement indéfini; sinon, il faut regarder comment ton compilateur traite les champs int.
Exactement.
-- __Pascal Bourguignon__ http://www.informatimago.com/ A bad day in () is better than a good day in {}.
Antoine Leca <root@localhost.invalid> writes:
Taurre écrivit :
Cependant, j'aimerais savoir ce qu'il en est pour les types entier
d'une taille inférieur à celle d'un int.
Comment fais-tu en C pour faire une opération arithmétique sur un entier
de taille strictement inférieure à celle d'un int ?
Mais ce n'est qu'une optimisation, sémantiquement, c'est comme si on
faisait l'opération sur un int.
Par exemple, si j'utilise un
champ de bits non signé de trois bits. Est-ce que je suis garantit
que, si ce dernier vaut 7 et que je l'incrémente, j'obtienne 0 ou
s'agit-il d'un comportement indéterminé?
Ni l'un ni l'autre ; tu es sûr d'obtenir 8, ce qui me paraît éminemment
raisonnable.
Maintenant, en dehors des considérations arithmétiques, si ta question
est, quelle sera la valeur du champ de bits si on y stocke 8 ? la
réponse est 0 parce qu'il est unsigned, en cohérence avec le point
ci-dessus; si le champ était signed tu aurais un comportement indéfini;
sinon, il faut regarder comment ton compilateur traite les champs int.
Exactement.
--
__Pascal Bourguignon__ http://www.informatimago.com/
A bad day in () is better than a good day in {}.
Mais ce n'est qu'une optimisation, sémantiquement, c'est comme si on faisait l'opération sur un int.
Par exemple, si j'utilise un champ de bits non signé de trois bits. Est-ce que je suis garantit que, si ce dernier vaut 7 et que je l'incrémente, j'obtienne 0 ou s'agit-il d'un comportement indéterminé?
Ni l'un ni l'autre ; tu es sûr d'obtenir 8, ce qui me paraît éminemment raisonnable.
Maintenant, en dehors des considérations arithmétiques, si ta question est, quelle sera la valeur du champ de bits si on y stocke 8 ? la réponse est 0 parce qu'il est unsigned, en cohérence avec le point ci-dessus; si le champ était signed tu aurais un comportement indéfini; sinon, il faut regarder comment ton compilateur traite les champs int.
Exactement.
-- __Pascal Bourguignon__ http://www.informatimago.com/ A bad day in () is better than a good day in {}.
Tonton Th
On 07/21/2011 11:33 AM, Antoine Leca wrote:
Par exemple, si j'utilise un champ de bits non signé de trois bits. Est-ce que je suis garantit que, si ce dernier vaut 7 et que je l'incrémente, j'obtienne 0 ou s'agit-il d'un comportement indéterminé?
Ni l'un ni l'autre ; tu es sûr d'obtenir 8, ce qui me paraît éminemment raisonnable.
Nous vivons dans un monde étrange/ http://foo.bar.quux.over-blog.com/
On 07/21/2011 11:33 AM, Antoine Leca wrote:
Par exemple, si j'utilise un
champ de bits non signé de trois bits. Est-ce que je suis garantit
que, si ce dernier vaut 7 et que je l'incrémente, j'obtienne 0 ou
s'agit-il d'un comportement indéterminé?
Ni l'un ni l'autre ; tu es sûr d'obtenir 8, ce qui me paraît éminemment
raisonnable.
Par exemple, si j'utilise un champ de bits non signé de trois bits. Est-ce que je suis garantit que, si ce dernier vaut 7 et que je l'incrémente, j'obtienne 0 ou s'agit-il d'un comportement indéterminé?
Ni l'un ni l'autre ; tu es sûr d'obtenir 8, ce qui me paraît éminemment raisonnable.
Nous vivons dans un monde étrange/ http://foo.bar.quux.over-blog.com/
Pierre Maurette
Taurre :
Bonjour à tous,
J'ai une question au sujet de l'arithmétique entière. Je sais que lorsque l'on dépasse la capacité d'un int, comme ceci par exemple:
int n = INT_MAX + 1;
il s'agit d'un comportement indéterminé et on ne peut donc pas être certains d'obtenir INT_MIN comme valeur. La même réflexion vaudrait pour un unsigned int.
Cependant, j'aimerais savoir ce qu'il en est pour les types entier d'une taille inférieur à celle d'un int. Par exemple, si j'utilise un champ de bits non signé de trois bits. Est-ce que je suis garantit que, si ce dernier vaut 7 et que je l'incrémente, j'obtienne 0 ou s'agit-il d'un comportement indéterminé?
Les types à taille fixe intN_t et uintN_t de stdint.h ont quand ils existent (!!) une représention garantie. Je ne suis pas sûr de ce que dit la norme sur leur comportement au dépassement pour les types signés. Mais il me semble que la prévisibilité de la représentation induit celle de l'arithmétique, avec un cast un peu glauque au besoin. stdint.h est C99 mais c'est une extension courante. Il est possible d'ajouter stdint.h dans un projet Visual Studio. Je ne sais pas s'il peut y avoir des effets pervers (en plus des problèmes de printf) à utiliser stdint.h dans un projet C89.
-- Pierre Maurette
Taurre :
Bonjour à tous,
J'ai une question au sujet de l'arithmétique entière.
Je sais que lorsque l'on dépasse la capacité d'un int, comme ceci par
exemple:
int n = INT_MAX + 1;
il s'agit d'un comportement indéterminé et on ne peut donc pas être
certains d'obtenir INT_MIN comme valeur. La même réflexion vaudrait
pour un unsigned int.
Cependant, j'aimerais savoir ce qu'il en est pour les types entier
d'une taille inférieur à celle d'un int. Par exemple, si j'utilise un
champ de bits non signé de trois bits. Est-ce que je suis garantit
que, si ce dernier vaut 7 et que je l'incrémente, j'obtienne 0 ou
s'agit-il d'un comportement indéterminé?
Les types à taille fixe intN_t et uintN_t de stdint.h ont quand ils
existent (!!) une représention garantie. Je ne suis pas sûr de ce que
dit la norme sur leur comportement au dépassement pour les types
signés. Mais il me semble que la prévisibilité de la représentation
induit celle de l'arithmétique, avec un cast un peu glauque au besoin.
stdint.h est C99 mais c'est une extension courante. Il est possible
d'ajouter stdint.h dans un projet Visual Studio. Je ne sais pas s'il
peut y avoir des effets pervers (en plus des problèmes de printf) à
utiliser stdint.h dans un projet C89.
J'ai une question au sujet de l'arithmétique entière. Je sais que lorsque l'on dépasse la capacité d'un int, comme ceci par exemple:
int n = INT_MAX + 1;
il s'agit d'un comportement indéterminé et on ne peut donc pas être certains d'obtenir INT_MIN comme valeur. La même réflexion vaudrait pour un unsigned int.
Cependant, j'aimerais savoir ce qu'il en est pour les types entier d'une taille inférieur à celle d'un int. Par exemple, si j'utilise un champ de bits non signé de trois bits. Est-ce que je suis garantit que, si ce dernier vaut 7 et que je l'incrémente, j'obtienne 0 ou s'agit-il d'un comportement indéterminé?
Les types à taille fixe intN_t et uintN_t de stdint.h ont quand ils existent (!!) une représention garantie. Je ne suis pas sûr de ce que dit la norme sur leur comportement au dépassement pour les types signés. Mais il me semble que la prévisibilité de la représentation induit celle de l'arithmétique, avec un cast un peu glauque au besoin. stdint.h est C99 mais c'est une extension courante. Il est possible d'ajouter stdint.h dans un projet Visual Studio. Je ne sais pas s'il peut y avoir des effets pervers (en plus des problèmes de printf) à utiliser stdint.h dans un projet C89.
-- Pierre Maurette
Antoine Leca
Tonton Th écrivit :
On 07/21/2011 11:33 AM, Antoine Leca wrote:
Par exemple, si j'utilise un champ de bits non signé de trois bits. Est-ce que je suis garantit que, si ce dernier vaut 7 et que je l'incrémente, j'obtienne 0 ou s'agit-il d'un comportement indéterminé?
Ni l'un ni l'autre ; tu es sûr d'obtenir 8, ce qui me paraît éminemment raisonnable.
Objection, votre honneur !
<...>
for (foo=0; foo<10; foo++) {
L'opération arithmétique d'incrémentation s'écrit
foo + 1
Tu utilises un opérateur du langage, qui d'une part implique une opération, et d'autre part a des « effets de bord » (en l'occurrence un stockage), lesquels ne sont pas des propriétés arithmétiques.
Dans la partie que tu as coupée, j'explicite pourquoi le 8 se transforme en 0.
Antoine
Tonton Th écrivit :
On 07/21/2011 11:33 AM, Antoine Leca wrote:
Par exemple, si j'utilise un
champ de bits non signé de trois bits. Est-ce que je suis garantit
que, si ce dernier vaut 7 et que je l'incrémente, j'obtienne 0 ou
s'agit-il d'un comportement indéterminé?
Ni l'un ni l'autre ; tu es sûr d'obtenir 8, ce qui me paraît éminemment
raisonnable.
Objection, votre honneur !
<...>
for (foo=0; foo<10; foo++) {
L'opération arithmétique d'incrémentation s'écrit
foo + 1
Tu utilises un opérateur du langage, qui d'une part implique une
opération, et d'autre part a des « effets de bord » (en l'occurrence un
stockage), lesquels ne sont pas des propriétés arithmétiques.
Dans la partie que tu as coupée, j'explicite pourquoi le 8 se transforme
en 0.
Par exemple, si j'utilise un champ de bits non signé de trois bits. Est-ce que je suis garantit que, si ce dernier vaut 7 et que je l'incrémente, j'obtienne 0 ou s'agit-il d'un comportement indéterminé?
Ni l'un ni l'autre ; tu es sûr d'obtenir 8, ce qui me paraît éminemment raisonnable.
Objection, votre honneur !
<...>
for (foo=0; foo<10; foo++) {
L'opération arithmétique d'incrémentation s'écrit
foo + 1
Tu utilises un opérateur du langage, qui d'une part implique une opération, et d'autre part a des « effets de bord » (en l'occurrence un stockage), lesquels ne sont pas des propriétés arithmétiques.
Dans la partie que tu as coupée, j'explicite pourquoi le 8 se transforme en 0.
Antoine
Antoine Leca
Pierre Maurette écrivit :
Les types à taille fixe intN_t et uintN_t de stdint.h ont quand ils existent (!!)
Le correctif technique nº2 à C99 a rendu obligatoire la définition de ces types si la machine sous-jacente en dispose.
une représention garantie. Je ne suis pas sûr de ce que dit la norme sur leur comportement au dépassement pour les types signés.
Rien de particulier, comportement indéfini dans le cas le plus général. Par exemple, il est parfaitement possible d'avoir une arithmétique saturée pour ces types, en particulier si leur taille est supérieure ou égale à celle de int ; ou de déclencher un déroutement...
Par contre, pour les types de taille strictement inférieure, comme le résultat des opérateurs arithmétiques sera int
Mais il me semble que la prévisibilité de la représentation induit celle de l'arithmétique, avec un cast un peu glauque au besoin.
Certes, avec /des/ transtypages tu peux forcer le comportement «habituel». Mais bon, trois transtypages à chaque opérateur binaire, cela va vite faire lourd voire indigeste...
stdint.h est C99 mais c'est une extension courante. Il est possible d'ajouter stdint.h dans un projet Visual Studio. Je ne sais pas s'il peut y avoir des effets pervers (en plus des problèmes de printf) à utiliser stdint.h dans un projet C89.
Je n'en vois pas non plus.
Antoine
Pierre Maurette écrivit :
Les types à taille fixe intN_t et uintN_t de stdint.h ont quand ils
existent (!!)
Le correctif technique nº2 à C99 a rendu obligatoire la définition de
ces types si la machine sous-jacente en dispose.
une représention garantie. Je ne suis pas sûr de ce que
dit la norme sur leur comportement au dépassement pour les types signés.
Rien de particulier, comportement indéfini dans le cas le plus général.
Par exemple, il est parfaitement possible d'avoir une arithmétique
saturée pour ces types, en particulier si leur taille est supérieure ou
égale à celle de int ; ou de déclencher un déroutement...
Par contre, pour les types de taille strictement inférieure, comme le
résultat des opérateurs arithmétiques sera int
Mais il me semble que la prévisibilité de la représentation induit celle
de l'arithmétique, avec un cast un peu glauque au besoin.
Certes, avec /des/ transtypages tu peux forcer le comportement
«habituel». Mais bon, trois transtypages à chaque opérateur binaire,
cela va vite faire lourd voire indigeste...
stdint.h est C99 mais c'est une extension courante. Il est possible
d'ajouter stdint.h dans un projet Visual Studio. Je ne sais pas s'il
peut y avoir des effets pervers (en plus des problèmes de printf) à
utiliser stdint.h dans un projet C89.
Les types à taille fixe intN_t et uintN_t de stdint.h ont quand ils existent (!!)
Le correctif technique nº2 à C99 a rendu obligatoire la définition de ces types si la machine sous-jacente en dispose.
une représention garantie. Je ne suis pas sûr de ce que dit la norme sur leur comportement au dépassement pour les types signés.
Rien de particulier, comportement indéfini dans le cas le plus général. Par exemple, il est parfaitement possible d'avoir une arithmétique saturée pour ces types, en particulier si leur taille est supérieure ou égale à celle de int ; ou de déclencher un déroutement...
Par contre, pour les types de taille strictement inférieure, comme le résultat des opérateurs arithmétiques sera int
Mais il me semble que la prévisibilité de la représentation induit celle de l'arithmétique, avec un cast un peu glauque au besoin.
Certes, avec /des/ transtypages tu peux forcer le comportement «habituel». Mais bon, trois transtypages à chaque opérateur binaire, cela va vite faire lourd voire indigeste...
stdint.h est C99 mais c'est une extension courante. Il est possible d'ajouter stdint.h dans un projet Visual Studio. Je ne sais pas s'il peut y avoir des effets pervers (en plus des problèmes de printf) à utiliser stdint.h dans un projet C89.
Je n'en vois pas non plus.
Antoine
Tonton Th
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 ;)
--
Nous vivons dans un monde étrange/ http://foo.bar.quux.over-blog.com/
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 ;)
--
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 ;)
--
Nous vivons dans un monde étrange/ http://foo.bar.quux.over-blog.com/
espie
In article , Pierre Maurette wrote:
Je ne suis pas sûr de ce que dit la norme sur leur comportement au dépassement pour les types signés. Mais il me semble que la prévisibilité de la représentation induit celle de l'arithmétique, avec un cast un peu glauque au besoin.
Non, l'arithmetique sur les types signes fait toujours n'importe quoi en cas de depassement.
La representation est juste la pour te garantir que tu peux caster des valeurs raisonnables entre le type uint et le type int correspondant, et essayer de dire que ca va etre n bits de valeur, 1 bit de signe, et m bits de padding...
Au final, l'arithmetique sur les unsigned est previsible, et cette histoire de representation permet de rendre une bonne part des transtypages unsigned <-> signed, previsibles (e.g., dans les bons intervalles de valeur).
Combiner les deux releve quand meme de la haute voltige et du tube d'aspirine...
In article <mn.ab917db70187a189.79899@free.fr>,
Pierre Maurette <maurette.pierre@free.fr> wrote:
Je ne suis pas sûr de ce que
dit la norme sur leur comportement au dépassement pour les types
signés. Mais il me semble que la prévisibilité de la représentation
induit celle de l'arithmétique, avec un cast un peu glauque au besoin.
Non, l'arithmetique sur les types signes fait toujours n'importe quoi en
cas de depassement.
La representation est juste la pour te garantir que tu peux caster des
valeurs raisonnables entre le type uint et le type int correspondant, et
essayer de dire que ca va etre n bits de valeur, 1 bit de signe, et m bits
de padding...
Au final, l'arithmetique sur les unsigned est previsible, et cette histoire
de representation permet de rendre une bonne part des transtypages
unsigned <-> signed, previsibles (e.g., dans les bons intervalles de valeur).
Combiner les deux releve quand meme de la haute voltige et du tube d'aspirine...
Je ne suis pas sûr de ce que dit la norme sur leur comportement au dépassement pour les types signés. Mais il me semble que la prévisibilité de la représentation induit celle de l'arithmétique, avec un cast un peu glauque au besoin.
Non, l'arithmetique sur les types signes fait toujours n'importe quoi en cas de depassement.
La representation est juste la pour te garantir que tu peux caster des valeurs raisonnables entre le type uint et le type int correspondant, et essayer de dire que ca va etre n bits de valeur, 1 bit de signe, et m bits de padding...
Au final, l'arithmetique sur les unsigned est previsible, et cette histoire de representation permet de rendre une bonne part des transtypages unsigned <-> signed, previsibles (e.g., dans les bons intervalles de valeur).
Combiner les deux releve quand meme de la haute voltige et du tube d'aspirine...
Antoine Leca
On dirait qu'une phrase a sauté... :-(
Antoine Leca a écrit :
Pierre Maurette écrivit :
une représention garantie. Je ne suis pas sûr de ce que dit la norme sur leur comportement au dépassement pour les types signés.
Rien de particulier, comportement indéfini dans le cas le plus général.
<...>
Par contre, pour les types de taille strictement inférieure, comme le résultat des opérateurs arithmétiques sera int
[...], selon les opérateurs, le résultat pourra être défini. Par exemple, la somme ou la différence de deux int8_t (ou 3, jusqu'à 256 en fait) ne posera pas de soucis, d'éventuels débordements resteront toujours définis.
Idem pour la multiplication de 2 int8_t, [-16256..16384] c'est OK.
Antoine
On dirait qu'une phrase a sauté... :-(
Antoine Leca a écrit :
Pierre Maurette écrivit :
une représention garantie. Je ne suis pas sûr de ce que
dit la norme sur leur comportement au dépassement pour les types signés.
Rien de particulier, comportement indéfini dans le cas le plus général.
<...>
Par contre, pour les types de taille strictement inférieure, comme le
résultat des opérateurs arithmétiques sera int
[...], selon les opérateurs, le résultat pourra être défini.
Par exemple, la somme ou la différence de deux int8_t (ou 3, jusqu'à 256
en fait) ne posera pas de soucis, d'éventuels débordements resteront
toujours définis.
une représention garantie. Je ne suis pas sûr de ce que dit la norme sur leur comportement au dépassement pour les types signés.
Rien de particulier, comportement indéfini dans le cas le plus général.
<...>
Par contre, pour les types de taille strictement inférieure, comme le résultat des opérateurs arithmétiques sera int
[...], selon les opérateurs, le résultat pourra être défini. Par exemple, la somme ou la différence de deux int8_t (ou 3, jusqu'à 256 en fait) ne posera pas de soucis, d'éventuels débordements resteront toujours définis.
