je souhaiterais savoir ce que dit la norme vis à vis de la taille des
types simples... J'ai en tete le chose suivante :
char : 8 bits
short int : 16 bits
long : 32 bits
long long : 64 bits
int : taille native supportée par le processeur (dans le cas de
processeurs Intel x86 32 bits, ce serait donc 32 bits).
que dit la norme à ce niveau ?
est elle respectée par les compilateurs ?
A+
Yann
--
Yann Renard - To send me an email, remove no-spam sectionS :)
On Wed, 30 Aug 2006 10:47:38 +0200, Yann Renard <pas de mail> :
je souhaiterais savoir ce que dit la norme vis à vis de la taille des types simples... J'ai en tete le chose suivante :
que dit la norme à ce niveau ?
Pas grand-chose.
Elle dit juste que
1 == sizeof char <= sizeof short <= sizeof int <= sizeof long
long long : 64 bits
Je ne suis pas sûr que la norme parle de "long long".
est elle respectée par les compilateurs ?
Oui.
kanze
Fabien LE LEZ wrote:
On Wed, 30 Aug 2006 10:47:38 +0200, Yann Renard <pas de mail> :
je souhaiterais savoir ce que dit la norme vis à vis de la taille des types simples... J'ai en tete le chose suivante :
que dit la norme à ce niveau ?
Pas grand-chose.
Elle dit juste que
1 == sizeof char <= sizeof short <= sizeof int <= sizeof long
Elle spécifie aussi un intervale minimum que chaque type doit supporter :
signed unsigned char -127...127 0...255 short -32767...32767 0...65535 int -32767...32767 0...65535 long -2147483647...2147483647 0...4294967295
long long : 64 bits
Je ne suis pas sûr que la norme parle de "long long".
La norme C++, non. Mais la norme C, oui, et le brouillon actuel de la version future du C++ aussi. Pour long long, on a les intervales -(2^63-1)...(2^63-1) et 0...(2^64-1).
-- James Kanze GABI Software Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
Fabien LE LEZ wrote:
On Wed, 30 Aug 2006 10:47:38 +0200, Yann Renard <pas de mail> :
je souhaiterais savoir ce que dit la norme vis à vis de la
taille des types simples... J'ai en tete le chose suivante :
que dit la norme à ce niveau ?
Pas grand-chose.
Elle dit juste que
1 == sizeof char <= sizeof short <= sizeof int <= sizeof long
Elle spécifie aussi un intervale minimum que chaque type doit
supporter :
signed unsigned
char -127...127 0...255
short -32767...32767 0...65535
int -32767...32767 0...65535
long -2147483647...2147483647 0...4294967295
long long : 64 bits
Je ne suis pas sûr que la norme parle de "long long".
La norme C++, non. Mais la norme C, oui, et le brouillon actuel
de la version future du C++ aussi. Pour long long, on a les
intervales -(2^63-1)...(2^63-1) et 0...(2^64-1).
--
James Kanze GABI Software
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
On Wed, 30 Aug 2006 10:47:38 +0200, Yann Renard <pas de mail> :
je souhaiterais savoir ce que dit la norme vis à vis de la taille des types simples... J'ai en tete le chose suivante :
que dit la norme à ce niveau ?
Pas grand-chose.
Elle dit juste que
1 == sizeof char <= sizeof short <= sizeof int <= sizeof long
Elle spécifie aussi un intervale minimum que chaque type doit supporter :
signed unsigned char -127...127 0...255 short -32767...32767 0...65535 int -32767...32767 0...65535 long -2147483647...2147483647 0...4294967295
long long : 64 bits
Je ne suis pas sûr que la norme parle de "long long".
La norme C++, non. Mais la norme C, oui, et le brouillon actuel de la version future du C++ aussi. Pour long long, on a les intervales -(2^63-1)...(2^63-1) et 0...(2^64-1).
-- James Kanze GABI Software Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
Yann Renard
kanze wrote:
[...] Elle spécifie aussi un intervale minimum que chaque type doit supporter : signed unsigned char -127...127 0...255 short -32767...32767 0...65535 int -32767...32767 0...65535 long -2147483647...2147483647 0...4294967295 [...]
Ceci veut il dire que concernant les 'int' la norme n'est pas respectée (il me semble que les 'int' sur architecture 32 bits sont 32 bits donc plutôt comme tes 'long')
Qu'en est il des types flottants ?
Il me semble sans en être certain que : float -> 32 bits double -> 64 bits long double -> 80 bits
Yann -- Yann Renard - To send me an email, remove no-spam sectionS :)
kanze wrote:
[...]
Elle spécifie aussi un intervale minimum que chaque type doit
supporter :
signed unsigned
char -127...127 0...255
short -32767...32767 0...65535
int -32767...32767 0...65535
long -2147483647...2147483647 0...4294967295
[...]
Ceci veut il dire que concernant les 'int' la norme n'est pas respectée
(il me semble que les 'int' sur architecture 32 bits sont 32 bits donc
plutôt comme tes 'long')
Qu'en est il des types flottants ?
Il me semble sans en être certain que :
float -> 32 bits
double -> 64 bits
long double -> 80 bits
Yann
--
Yann Renard - To send me an email, remove no-spam sectionS :)
[...] Elle spécifie aussi un intervale minimum que chaque type doit supporter : signed unsigned char -127...127 0...255 short -32767...32767 0...65535 int -32767...32767 0...65535 long -2147483647...2147483647 0...4294967295 [...]
Ceci veut il dire que concernant les 'int' la norme n'est pas respectée (il me semble que les 'int' sur architecture 32 bits sont 32 bits donc plutôt comme tes 'long')
Qu'en est il des types flottants ?
Il me semble sans en être certain que : float -> 32 bits double -> 64 bits long double -> 80 bits
Yann -- Yann Renard - To send me an email, remove no-spam sectionS :)
Bruno CAUSSE
dans l'article 44f595fd$0$14785$, Yann Renard à a écrit le 30/08/06 15:39 :
Ceci veut il dire que concernant les 'int' la norme n'est pas respectée (il me semble que les 'int' sur architecture 32 bits sont 32 bits donc plutôt comme tes 'long')
Si, la norme donne le minimun, sur une architecture 64 bits un char peut avoir 64 bits par ex
dans l'article 44f595fd$0$14785$636a55ce@news.free.fr, Yann Renard à
maps.on-yann.renard.mailing-lists-no.spam@maps.on-tiscali-no.spam.fr a écrit
le 30/08/06 15:39 :
Ceci veut il dire que concernant les 'int' la norme n'est pas respectée
(il me semble que les 'int' sur architecture 32 bits sont 32 bits donc
plutôt comme tes 'long')
Si, la norme donne le minimun, sur une architecture 64 bits un char peut
avoir 64 bits par ex
dans l'article 44f595fd$0$14785$, Yann Renard à a écrit le 30/08/06 15:39 :
Ceci veut il dire que concernant les 'int' la norme n'est pas respectée (il me semble que les 'int' sur architecture 32 bits sont 32 bits donc plutôt comme tes 'long')
Si, la norme donne le minimun, sur une architecture 64 bits un char peut avoir 64 bits par ex
kanze
Yann Renard wrote:
kanze wrote:
[...] Elle spécifie aussi un intervale minimum que chaque type doit supporter : signed unsigned char -127...127 0...255 short -32767...32767 0...65535 int -32767...32767 0...65535 long -2147483647...2147483647 0...4294967295 [...]
Ceci veut il dire que concernant les 'int' la norme n'est pas respectée (il me semble que les 'int' sur architecture 32 bits sont 32 bits donc plutôt comme tes 'long')
C'est un minimum. L'implémentation a le droit de faire plus ; en fait, je ne connais pas d'implémentation qui n'en fait pas plus. Régarde bien les minimums des valeurs signées. Ils sont conçus pour permettre du complément à 1 ou de la magnitude signée. Or, la seule machine actuelle que je connais à complément à un est à 36 bits. Avec donc des char de 9 bits, intervale -255...255, etc., et non -127...127.
D'après ce que j'ai entendu, certains DSP utilisent 32 bits pour tous les types, avec sizeof long == 1 (et CHAR_BIT == 32). Je crois qu'il y a un peu de question si c'est légal dans une inplémentation herbergée, parce qu'il ne permet pas de distinguer entre EOF et une valeur qui tient dans un unsigned char, mais sur des implémentations non-herbergées, c'est certainement légal.
Qu'en est il des types flottants ?
Il me semble sans en être certain que : float -> 32 bits double -> 64 bits long double -> 80 bits
Sur l'architecture IA-32 d'Intel (et pas toujours, alors). La norme laisse beaucoup plus de liberté : elle démande une précision d'au moins 6 chiffres décimal pour float, et 10 pour double et long double, et une valeur maximum d'au moins 1E37 dans tous les cas.
Il y a aussi une exigeance que : sizeof(char) <= sizeof(float) <= sizeof(double) <= sizeof(long double). Et que les mêmes rapports tiennent (sauf pour char) pour les précisions et les valeurs maximum.
Même quand les float ont 32 bits, il reste de grosses différences : la valeur maximum des float IBM est de l'ordre de 1E76 ou 1E77, alors que ce n'est que de 3.402823466E+38F sur mon Sun Sparc, bien que tous les deux ont 32 bits.
-- James Kanze GABI Software Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
Yann Renard wrote:
kanze wrote:
[...]
Elle spécifie aussi un intervale minimum que chaque type doit
supporter :
signed unsigned
char -127...127 0...255
short -32767...32767 0...65535
int -32767...32767 0...65535
long -2147483647...2147483647 0...4294967295
[...]
Ceci veut il dire que concernant les 'int' la norme n'est pas
respectée (il me semble que les 'int' sur architecture 32 bits
sont 32 bits donc plutôt comme tes 'long')
C'est un minimum. L'implémentation a le droit de faire plus ;
en fait, je ne connais pas d'implémentation qui n'en fait pas
plus. Régarde bien les minimums des valeurs signées. Ils sont
conçus pour permettre du complément à 1 ou de la magnitude
signée. Or, la seule machine actuelle que je connais à
complément à un est à 36 bits. Avec donc des char de 9 bits,
intervale -255...255, etc., et non -127...127.
D'après ce que j'ai entendu, certains DSP utilisent 32 bits pour
tous les types, avec sizeof long == 1 (et CHAR_BIT == 32). Je
crois qu'il y a un peu de question si c'est légal dans une
inplémentation herbergée, parce qu'il ne permet pas de
distinguer entre EOF et une valeur qui tient dans un unsigned
char, mais sur des implémentations non-herbergées, c'est
certainement légal.
Qu'en est il des types flottants ?
Il me semble sans en être certain que :
float -> 32 bits
double -> 64 bits
long double -> 80 bits
Sur l'architecture IA-32 d'Intel (et pas toujours, alors). La
norme laisse beaucoup plus de liberté : elle démande une
précision d'au moins 6 chiffres décimal pour float, et 10 pour
double et long double, et une valeur maximum d'au moins 1E37
dans tous les cas.
Il y a aussi une exigeance que : sizeof(char) <= sizeof(float)
<= sizeof(double) <= sizeof(long double). Et que les mêmes
rapports tiennent (sauf pour char) pour les précisions et les
valeurs maximum.
Même quand les float ont 32 bits, il reste de grosses
différences : la valeur maximum des float IBM est de l'ordre de
1E76 ou 1E77, alors que ce n'est que de 3.402823466E+38F sur mon
Sun Sparc, bien que tous les deux ont 32 bits.
--
James Kanze GABI Software
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
[...] Elle spécifie aussi un intervale minimum que chaque type doit supporter : signed unsigned char -127...127 0...255 short -32767...32767 0...65535 int -32767...32767 0...65535 long -2147483647...2147483647 0...4294967295 [...]
Ceci veut il dire que concernant les 'int' la norme n'est pas respectée (il me semble que les 'int' sur architecture 32 bits sont 32 bits donc plutôt comme tes 'long')
C'est un minimum. L'implémentation a le droit de faire plus ; en fait, je ne connais pas d'implémentation qui n'en fait pas plus. Régarde bien les minimums des valeurs signées. Ils sont conçus pour permettre du complément à 1 ou de la magnitude signée. Or, la seule machine actuelle que je connais à complément à un est à 36 bits. Avec donc des char de 9 bits, intervale -255...255, etc., et non -127...127.
D'après ce que j'ai entendu, certains DSP utilisent 32 bits pour tous les types, avec sizeof long == 1 (et CHAR_BIT == 32). Je crois qu'il y a un peu de question si c'est légal dans une inplémentation herbergée, parce qu'il ne permet pas de distinguer entre EOF et une valeur qui tient dans un unsigned char, mais sur des implémentations non-herbergées, c'est certainement légal.
Qu'en est il des types flottants ?
Il me semble sans en être certain que : float -> 32 bits double -> 64 bits long double -> 80 bits
Sur l'architecture IA-32 d'Intel (et pas toujours, alors). La norme laisse beaucoup plus de liberté : elle démande une précision d'au moins 6 chiffres décimal pour float, et 10 pour double et long double, et une valeur maximum d'au moins 1E37 dans tous les cas.
Il y a aussi une exigeance que : sizeof(char) <= sizeof(float) <= sizeof(double) <= sizeof(long double). Et que les mêmes rapports tiennent (sauf pour char) pour les précisions et les valeurs maximum.
Même quand les float ont 32 bits, il reste de grosses différences : la valeur maximum des float IBM est de l'ordre de 1E76 ou 1E77, alors que ce n'est que de 3.402823466E+38F sur mon Sun Sparc, bien que tous les deux ont 32 bits.
-- James Kanze GABI Software Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
Yann Renard
kanze wrote:
Yann Renard wrote:
kanze wrote:
[...] Elle spécifie aussi un intervale minimum que chaque type doit supporter : signed unsigned char -127...127 0...255 short -32767...32767 0...65535 int -32767...32767 0...65535 long -2147483647...2147483647 0...4294967295 [...]
Ceci veut il dire que concernant les 'int' la norme n'est pas respectée (il me semble que les 'int' sur architecture 32 bits sont 32 bits donc plutôt comme tes 'long')
C'est un minimum. L'implémentation a le droit de faire plus ; en fait, je ne connais pas d'implémentation qui n'en fait pas plus. Régarde bien les minimums des valeurs signées. Ils sont conçus pour permettre du complément à 1 ou de la magnitude signée. Or, la seule machine actuelle que je connais à complément à un est à 36 bits. Avec donc des char de 9 bits, intervale -255...255, etc., et non -127...127.
Ah oui, exact :o)
D'après ce que j'ai entendu, certains DSP utilisent 32 bits pour tous les types, avec sizeof long == 1 (et CHAR_BIT == 32). Je crois qu'il y a un peu de question si c'est légal dans une inplémentation herbergée, parce qu'il ne permet pas de distinguer entre EOF et une valeur qui tient dans un unsigned char, mais sur des implémentations non-herbergées, c'est certainement légal.
Qu'en est il des types flottants ?
Il me semble sans en être certain que : float -> 32 bits double -> 64 bits long double -> 80 bits
Sur l'architecture IA-32 d'Intel (et pas toujours, alors). La norme laisse beaucoup plus de liberté : elle démande une précision d'au moins 6 chiffres décimal pour float, et 10 pour double et long double, et une valeur maximum d'au moins 1E37 dans tous les cas.
Il y a aussi une exigeance que : sizeof(char) <= sizeof(float) <= sizeof(double) <= sizeof(long double). Et que les mêmes rapports tiennent (sauf pour char) pour les précisions et les valeurs maximum.
Même quand les float ont 32 bits, il reste de grosses différences : la valeur maximum des float IBM est de l'ordre de 1E76 ou 1E77, alors que ce n'est que de 3.402823466E+38F sur mon Sun Sparc, bien que tous les deux ont 32 bits.
Il y a pourtant bien une norme IEEE sur la représentation des nombres flottants en mantisse exposant (je ne sais plus laquelle d'ailleurs mais ça doit se retrouver). D'après ce que tu dis, cela signifie que cette norme n'est pas non plus appliquée par tous les hardware ?
Finalement, de ce que j'en vois, quoi qu'il arrive, ce que spécifie la norme de C++ est de toute façon un minimum et non pas ce qu'il y a en réalité, que ce qu'il y a en réalité est spécifié par des normes différentes (relatives au hard probablement) et que celles ci peuvent en plus être différentes d'un hard à l'autre...
Le bonheur quoi :o)
Yann
kanze wrote:
Yann Renard wrote:
kanze wrote:
[...]
Elle spécifie aussi un intervale minimum que chaque type doit
supporter :
signed unsigned
char -127...127 0...255
short -32767...32767 0...65535
int -32767...32767 0...65535
long -2147483647...2147483647 0...4294967295
[...]
Ceci veut il dire que concernant les 'int' la norme n'est pas
respectée (il me semble que les 'int' sur architecture 32 bits
sont 32 bits donc plutôt comme tes 'long')
C'est un minimum. L'implémentation a le droit de faire plus ;
en fait, je ne connais pas d'implémentation qui n'en fait pas
plus. Régarde bien les minimums des valeurs signées. Ils sont
conçus pour permettre du complément à 1 ou de la magnitude
signée. Or, la seule machine actuelle que je connais à
complément à un est à 36 bits. Avec donc des char de 9 bits,
intervale -255...255, etc., et non -127...127.
Ah oui, exact :o)
D'après ce que j'ai entendu, certains DSP utilisent 32 bits pour
tous les types, avec sizeof long == 1 (et CHAR_BIT == 32). Je
crois qu'il y a un peu de question si c'est légal dans une
inplémentation herbergée, parce qu'il ne permet pas de
distinguer entre EOF et une valeur qui tient dans un unsigned
char, mais sur des implémentations non-herbergées, c'est
certainement légal.
Qu'en est il des types flottants ?
Il me semble sans en être certain que :
float -> 32 bits
double -> 64 bits
long double -> 80 bits
Sur l'architecture IA-32 d'Intel (et pas toujours, alors). La
norme laisse beaucoup plus de liberté : elle démande une
précision d'au moins 6 chiffres décimal pour float, et 10 pour
double et long double, et une valeur maximum d'au moins 1E37
dans tous les cas.
Il y a aussi une exigeance que : sizeof(char) <= sizeof(float)
<= sizeof(double) <= sizeof(long double). Et que les mêmes
rapports tiennent (sauf pour char) pour les précisions et les
valeurs maximum.
Même quand les float ont 32 bits, il reste de grosses
différences : la valeur maximum des float IBM est de l'ordre de
1E76 ou 1E77, alors que ce n'est que de 3.402823466E+38F sur mon
Sun Sparc, bien que tous les deux ont 32 bits.
Il y a pourtant bien une norme IEEE sur la représentation des nombres
flottants en mantisse exposant (je ne sais plus laquelle d'ailleurs mais
ça doit se retrouver). D'après ce que tu dis, cela signifie que cette
norme n'est pas non plus appliquée par tous les hardware ?
Finalement, de ce que j'en vois, quoi qu'il arrive, ce que spécifie la
norme de C++ est de toute façon un minimum et non pas ce qu'il y a en
réalité, que ce qu'il y a en réalité est spécifié par des normes
différentes (relatives au hard probablement) et que celles ci peuvent en
plus être différentes d'un hard à l'autre...
[...] Elle spécifie aussi un intervale minimum que chaque type doit supporter : signed unsigned char -127...127 0...255 short -32767...32767 0...65535 int -32767...32767 0...65535 long -2147483647...2147483647 0...4294967295 [...]
Ceci veut il dire que concernant les 'int' la norme n'est pas respectée (il me semble que les 'int' sur architecture 32 bits sont 32 bits donc plutôt comme tes 'long')
C'est un minimum. L'implémentation a le droit de faire plus ; en fait, je ne connais pas d'implémentation qui n'en fait pas plus. Régarde bien les minimums des valeurs signées. Ils sont conçus pour permettre du complément à 1 ou de la magnitude signée. Or, la seule machine actuelle que je connais à complément à un est à 36 bits. Avec donc des char de 9 bits, intervale -255...255, etc., et non -127...127.
Ah oui, exact :o)
D'après ce que j'ai entendu, certains DSP utilisent 32 bits pour tous les types, avec sizeof long == 1 (et CHAR_BIT == 32). Je crois qu'il y a un peu de question si c'est légal dans une inplémentation herbergée, parce qu'il ne permet pas de distinguer entre EOF et une valeur qui tient dans un unsigned char, mais sur des implémentations non-herbergées, c'est certainement légal.
Qu'en est il des types flottants ?
Il me semble sans en être certain que : float -> 32 bits double -> 64 bits long double -> 80 bits
Sur l'architecture IA-32 d'Intel (et pas toujours, alors). La norme laisse beaucoup plus de liberté : elle démande une précision d'au moins 6 chiffres décimal pour float, et 10 pour double et long double, et une valeur maximum d'au moins 1E37 dans tous les cas.
Il y a aussi une exigeance que : sizeof(char) <= sizeof(float) <= sizeof(double) <= sizeof(long double). Et que les mêmes rapports tiennent (sauf pour char) pour les précisions et les valeurs maximum.
Même quand les float ont 32 bits, il reste de grosses différences : la valeur maximum des float IBM est de l'ordre de 1E76 ou 1E77, alors que ce n'est que de 3.402823466E+38F sur mon Sun Sparc, bien que tous les deux ont 32 bits.
Il y a pourtant bien une norme IEEE sur la représentation des nombres flottants en mantisse exposant (je ne sais plus laquelle d'ailleurs mais ça doit se retrouver). D'après ce que tu dis, cela signifie que cette norme n'est pas non plus appliquée par tous les hardware ?
Finalement, de ce que j'en vois, quoi qu'il arrive, ce que spécifie la norme de C++ est de toute façon un minimum et non pas ce qu'il y a en réalité, que ce qu'il y a en réalité est spécifié par des normes différentes (relatives au hard probablement) et que celles ci peuvent en plus être différentes d'un hard à l'autre...
Le bonheur quoi :o)
Yann
Fabien LE LEZ
On 31 Aug 2006 00:48:02 -0700, "kanze" :
inplémentation herbergée
De quoi s'agit-il ?
On 31 Aug 2006 00:48:02 -0700, "kanze" <kanze@gabi-soft.fr>:
