J'ai une question à priori idiote mais peut-être pas autant que ça.
En fait c'est plus un problème de comprendre correctement une
question qui est en anglais. Il y en a deux, les voici :
int *p;
1. How can we have p address ?
2. How can we have the address contained by p ?
Il me semble que le sujet a déjà été évoqué dans ce forum, et que char valait 1 octet quelque soit l'architecture
Non, 1 byte, qui ne fait pas nécessairement 8 bits, et n'équivaut donc pas à un octet.
Vincent Guichard
Eric Lévénez wrote:
Non. sizeof ne retourne pas la taille en octet, mais en char. Un char a une taille variable suivant les architectures et les compilateurs.
Ahhhhh ??!
Il me semble que le sujet a déjà été évoqué dans ce forum, et que char valait 1 octet quelque soit l'architecture ( ce qui motivait l'utilisation de "1" plutôt que de "sizeof(char)" ).
Dans mon K&R2, je trouve ça:
"char character - a single byte" (p. 9) "char a single byte, capable of holding one character in the local character set" (p. 36) "when sizeof is applied to a char, the result is 1" (p. 204)
Quid ?
Le problème, c'est qu'un _Octet_ (fr), c'est _8_ bits. Alors qu'un _Byte_ (en), c'est _n_ bits. La tradution en français de _Byte_, c'est multiplet (si je me souviens bien). La traduction en anglais de _Octet_ ça doit être quelque chose comme _Eight-Bits Byte_.
On trouve de plus en plus d'architectures avec des multiplets de 16, voire 32 bits.
Vincent Guichard
Eric Lévénez wrote:
Non. sizeof ne retourne pas la taille en octet, mais en char. Un char
a une
taille variable suivant les architectures et les compilateurs.
Ahhhhh ??!
Il me semble que le sujet a déjà été évoqué dans ce forum, et que char
valait 1 octet quelque soit l'architecture ( ce qui motivait
l'utilisation de "1" plutôt que de "sizeof(char)" ).
Dans mon K&R2, je trouve ça:
"char character - a single byte" (p. 9)
"char a single byte, capable of holding one character in the local
character set" (p. 36)
"when sizeof is applied to a char, the result is 1" (p. 204)
Quid ?
Le problème, c'est qu'un _Octet_ (fr), c'est _8_ bits. Alors qu'un
_Byte_ (en), c'est _n_ bits. La tradution en français de _Byte_, c'est
multiplet (si je me souviens bien). La traduction en anglais de _Octet_
ça doit être quelque chose comme _Eight-Bits Byte_.
On trouve de plus en plus d'architectures avec des multiplets de 16,
voire 32 bits.
Non. sizeof ne retourne pas la taille en octet, mais en char. Un char a une taille variable suivant les architectures et les compilateurs.
Ahhhhh ??!
Il me semble que le sujet a déjà été évoqué dans ce forum, et que char valait 1 octet quelque soit l'architecture ( ce qui motivait l'utilisation de "1" plutôt que de "sizeof(char)" ).
Dans mon K&R2, je trouve ça:
"char character - a single byte" (p. 9) "char a single byte, capable of holding one character in the local character set" (p. 36) "when sizeof is applied to a char, the result is 1" (p. 204)
Quid ?
Le problème, c'est qu'un _Octet_ (fr), c'est _8_ bits. Alors qu'un _Byte_ (en), c'est _n_ bits. La tradution en français de _Byte_, c'est multiplet (si je me souviens bien). La traduction en anglais de _Octet_ ça doit être quelque chose comme _Eight-Bits Byte_.
On trouve de plus en plus d'architectures avec des multiplets de 16, voire 32 bits.
Vincent Guichard
Emmanuel Delahaye
gregg wrote on 13/01/05 :
Eric Lévénez wrote:
Non. sizeof ne retourne pas la taille en octet, mais en char. Un char a une taille variable suivant les architectures et les compilateurs.
Ahhhhh ??!
Il me semble que le sujet a déjà été évoqué dans ce forum, et que char valait 1 octet quelque soit l'architecture ( ce qui motivait l'utilisation de "1" plutôt que de "sizeof(char)" ).
Le char vaut 1 byte, pas 1 octet.
Dans mon K&R2, je trouve ça:
"char character - a single byte" (p. 9) "char a single byte, capable of holding one character in the local character set" (p. 36) "when sizeof is applied to a char, the result is 1" (p. 204)
Quid ?
Il ne faut pas confondre octet (objet de strictement 8-bit) et byte (plus petit objet adressable >= 8-bit d'une architecture donnée. Le nombre de bits par byte de ton implémentation est indiquée par définition de la macro CHAR_BIT dans <limits.h>
-- Emmanuel The C-FAQ: http://www.eskimo.com/~scs/C-faq/faq.html The C-library: http://www.dinkumware.com/refxc.html
"C is a sharp tool"
gregg wrote on 13/01/05 :
Eric Lévénez wrote:
Non. sizeof ne retourne pas la taille en octet, mais en char. Un char a une
taille variable suivant les architectures et les compilateurs.
Ahhhhh ??!
Il me semble que le sujet a déjà été évoqué dans ce forum, et que char valait
1 octet quelque soit l'architecture ( ce qui motivait l'utilisation de "1"
plutôt que de "sizeof(char)" ).
Le char vaut 1 byte, pas 1 octet.
Dans mon K&R2, je trouve ça:
"char character - a single byte" (p. 9)
"char a single byte, capable of holding one character in the local
character set" (p. 36)
"when sizeof is applied to a char, the result is 1" (p. 204)
Quid ?
Il ne faut pas confondre octet (objet de strictement 8-bit) et byte
(plus petit objet adressable >= 8-bit d'une architecture donnée. Le
nombre de bits par byte de ton implémentation est indiquée par
définition de la macro CHAR_BIT dans <limits.h>
--
Emmanuel
The C-FAQ: http://www.eskimo.com/~scs/C-faq/faq.html
The C-library: http://www.dinkumware.com/refxc.html
Non. sizeof ne retourne pas la taille en octet, mais en char. Un char a une taille variable suivant les architectures et les compilateurs.
Ahhhhh ??!
Il me semble que le sujet a déjà été évoqué dans ce forum, et que char valait 1 octet quelque soit l'architecture ( ce qui motivait l'utilisation de "1" plutôt que de "sizeof(char)" ).
Le char vaut 1 byte, pas 1 octet.
Dans mon K&R2, je trouve ça:
"char character - a single byte" (p. 9) "char a single byte, capable of holding one character in the local character set" (p. 36) "when sizeof is applied to a char, the result is 1" (p. 204)
Quid ?
Il ne faut pas confondre octet (objet de strictement 8-bit) et byte (plus petit objet adressable >= 8-bit d'une architecture donnée. Le nombre de bits par byte de ton implémentation est indiquée par définition de la macro CHAR_BIT dans <limits.h>
-- Emmanuel The C-FAQ: http://www.eskimo.com/~scs/C-faq/faq.html The C-library: http://www.dinkumware.com/refxc.html
"C is a sharp tool"
Emmanuel Delahaye
Vincent Guichard wrote on 13/01/05 :
La traduction en anglais de _Octet_ ça doit être quelque chose comme _Eight-Bits Byte_.
Ou 'octet' tout simplement. C'est aussi un mot anglais. (On prononce le 't' final)
-- Emmanuel The C-FAQ: http://www.eskimo.com/~scs/C-faq/faq.html The C-library: http://www.dinkumware.com/refxc.html
"Mal nommer les choses c'est ajouter du malheur au monde." -- Albert Camus.
Vincent Guichard wrote on 13/01/05 :
La traduction en anglais de _Octet_
ça doit être quelque chose comme _Eight-Bits Byte_.
Ou 'octet' tout simplement. C'est aussi un mot anglais. (On prononce le
't' final)
--
Emmanuel
The C-FAQ: http://www.eskimo.com/~scs/C-faq/faq.html
The C-library: http://www.dinkumware.com/refxc.html
"Mal nommer les choses c'est ajouter du malheur au
monde." -- Albert Camus.
Que renvoi un sizeof(toto) ? Et surtout... pourquoi ? :)
Attention, sizeof n'est pas une fonction, (qui renvoie une valeur), mais un opérateur.
Les écritures sont sizeof objet ou sizeof(type).
int i; size_t taille_int = sizeof i; // ok taille_int = sizeof(int); // ok taille_int = sizeof int; // erreur
Le compilateur calcule cette valeur et l'utilise directement dans le binaire.
Nicolas.
James Kanze
TigrouMeow wrote:
Soit la structure : struct toto { int a; long b; char c; };
Que renvoi un sizeof(toto) ?
Rien.
Et surtout... pourquoi ? :)
Parce que cela donnera une erreur de syntaxe.
Oui bon c'est vrai, il y a une erreur de syntaxe... soit sizeof(struct toto). (et qui donne 12 octets).
Curieux. J'obtiens 24 sur mon Sparc (en mode 64 bits). Et j'obtenais 8 avec le vieux compilo 16 bits sous MS-DOS. Sans parler du 18 sur un Unisys series A, et 3 sur certains DSP.
Je voulais en venir ensuite par l'utilisation de : __attribute__ ((__packed__)). (qui permet d'avoir une struct de 9 octets pour le même contenu).
Oui, mais ce n'est pas du C.
En fait j'ai cherché des explications sur google, il y a bien des documents en anglais, mais je comprends pas très bien ce que ça fait, alors j'aurais aimé avoir une petite explication concise ;) Merci beaucoup !
D'une part, il y a la taille de chacun des éléments (qui dépend de l'implémentation), et de l'autre, le fait soit qu'il faut que des accès soient alignés, soit que l'accès est moins rapide s'il ne l'est pas. Sur ma machine habituelle, par exemple, les long font 8 octets, et doivent être alignés sur une adresse multiple de huit. Du coup, il y a quatre octets pour a, quatre octets de rembourage pour que b soit aligné, huit octets de b, un octet de c, puis 7 octets de rembourage pour que dans un tableau, l'élément suivant soit bien aligné aussi.
Dans le vieux compilo 16 bits MS-DOS, évidemment, les int était deux octets, les long quatre, et l'alignement maximum était de deux. Sur un Unisys series A, les int et les long était chacun 6 octets, qui était aussi l'alignement nécessaire, et sur certains DSP, les int, les long et les char ont tous une taille d'un. (Note bien que sizeof donne bien la taille en « bytes », non en octets.)
-- James Kanze home: www.gabi-soft.fr Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 pl. Pierre Sémard, 78210 St.-Cyr-l'École, France +33 (0)1 30 23 00 34
TigrouMeow wrote:
Soit la structure :
struct toto
{
int a;
long b;
char c;
};
Que renvoi un sizeof(toto) ?
Rien.
Et surtout... pourquoi ? :)
Parce que cela donnera une erreur de syntaxe.
Oui bon c'est vrai, il y a une erreur de syntaxe...
soit sizeof(struct toto).
(et qui donne 12 octets).
Curieux. J'obtiens 24 sur mon Sparc (en mode 64 bits). Et
j'obtenais 8 avec le vieux compilo 16 bits sous MS-DOS. Sans
parler du 18 sur un Unisys series A, et 3 sur certains DSP.
Je voulais en venir ensuite par l'utilisation de :
__attribute__ ((__packed__)). (qui permet d'avoir une struct
de 9 octets pour le même contenu).
Oui, mais ce n'est pas du C.
En fait j'ai cherché des explications sur google, il y a bien
des documents en anglais, mais je comprends pas très bien ce
que ça fait, alors j'aurais aimé avoir une petite explication
concise ;) Merci beaucoup !
D'une part, il y a la taille de chacun des éléments (qui dépend
de l'implémentation), et de l'autre, le fait soit qu'il faut que
des accès soient alignés, soit que l'accès est moins rapide s'il
ne l'est pas. Sur ma machine habituelle, par exemple, les long
font 8 octets, et doivent être alignés sur une adresse multiple
de huit. Du coup, il y a quatre octets pour a, quatre octets de
rembourage pour que b soit aligné, huit octets de b, un octet de
c, puis 7 octets de rembourage pour que dans un tableau,
l'élément suivant soit bien aligné aussi.
Dans le vieux compilo 16 bits MS-DOS, évidemment, les int était
deux octets, les long quatre, et l'alignement maximum était de
deux. Sur un Unisys series A, les int et les long était chacun 6
octets, qui était aussi l'alignement nécessaire, et sur certains
DSP, les int, les long et les char ont tous une taille d'un.
(Note bien que sizeof donne bien la taille en « bytes », non en
octets.)
--
James Kanze home: www.gabi-soft.fr
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 pl. Pierre Sémard, 78210 St.-Cyr-l'École, France +33 (0)1 30 23 00 34
Soit la structure : struct toto { int a; long b; char c; };
Que renvoi un sizeof(toto) ?
Rien.
Et surtout... pourquoi ? :)
Parce que cela donnera une erreur de syntaxe.
Oui bon c'est vrai, il y a une erreur de syntaxe... soit sizeof(struct toto). (et qui donne 12 octets).
Curieux. J'obtiens 24 sur mon Sparc (en mode 64 bits). Et j'obtenais 8 avec le vieux compilo 16 bits sous MS-DOS. Sans parler du 18 sur un Unisys series A, et 3 sur certains DSP.
Je voulais en venir ensuite par l'utilisation de : __attribute__ ((__packed__)). (qui permet d'avoir une struct de 9 octets pour le même contenu).
Oui, mais ce n'est pas du C.
En fait j'ai cherché des explications sur google, il y a bien des documents en anglais, mais je comprends pas très bien ce que ça fait, alors j'aurais aimé avoir une petite explication concise ;) Merci beaucoup !
D'une part, il y a la taille de chacun des éléments (qui dépend de l'implémentation), et de l'autre, le fait soit qu'il faut que des accès soient alignés, soit que l'accès est moins rapide s'il ne l'est pas. Sur ma machine habituelle, par exemple, les long font 8 octets, et doivent être alignés sur une adresse multiple de huit. Du coup, il y a quatre octets pour a, quatre octets de rembourage pour que b soit aligné, huit octets de b, un octet de c, puis 7 octets de rembourage pour que dans un tableau, l'élément suivant soit bien aligné aussi.
Dans le vieux compilo 16 bits MS-DOS, évidemment, les int était deux octets, les long quatre, et l'alignement maximum était de deux. Sur un Unisys series A, les int et les long était chacun 6 octets, qui était aussi l'alignement nécessaire, et sur certains DSP, les int, les long et les char ont tous une taille d'un. (Note bien que sizeof donne bien la taille en « bytes », non en octets.)
-- James Kanze home: www.gabi-soft.fr Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 pl. Pierre Sémard, 78210 St.-Cyr-l'École, France +33 (0)1 30 23 00 34
Horst Kraemer
Nicolas wrote:
Que renvoi un sizeof(toto) ? Et surtout... pourquoi ? :)
Attention, sizeof n'est pas une fonction, (qui renvoie une valeur), mais un opérateur.
Les écritures sont sizeof objet ou sizeof(type).
Les écritures sont
sizeof expression-unaire
ou
sizeof (nom de type)
Personne n'interdit de mettre des parenthèses autour d'une expression unaire parce que si EXP est une expression unaire alors (EXP) est aussi une expression unaire qui a la même taille. D'autre part il faut mettre des parenthèses dans l'expression
/* toto a; titi b; */
sizeof (a+b)
quand on veut déterminer la taille de l'expression a+b par ce que
sizeof a + b
est interprété comme
(sizeof a) + b
parce que a+b n'est pas d'expression unaire.
-- Horst
Nicolas <nicolas@none.com> wrote:
Que renvoi un sizeof(toto) ? Et surtout... pourquoi ? :)
Attention, sizeof n'est pas une fonction, (qui renvoie une valeur), mais
un opérateur.
Les écritures sont sizeof objet ou sizeof(type).
Les écritures sont
sizeof expression-unaire
ou
sizeof (nom de type)
Personne n'interdit de mettre des parenthèses autour d'une expression
unaire parce que si EXP est une expression unaire alors (EXP) est
aussi une expression unaire qui a la même taille. D'autre part il faut
mettre des parenthèses dans l'expression
/* toto a; titi b; */
sizeof (a+b)
quand on veut déterminer la taille de l'expression a+b par ce que
Que renvoi un sizeof(toto) ? Et surtout... pourquoi ? :)
Attention, sizeof n'est pas une fonction, (qui renvoie une valeur), mais un opérateur.
Les écritures sont sizeof objet ou sizeof(type).
Les écritures sont
sizeof expression-unaire
ou
sizeof (nom de type)
Personne n'interdit de mettre des parenthèses autour d'une expression unaire parce que si EXP est une expression unaire alors (EXP) est aussi une expression unaire qui a la même taille. D'autre part il faut mettre des parenthèses dans l'expression
/* toto a; titi b; */
sizeof (a+b)
quand on veut déterminer la taille de l'expression a+b par ce que
sizeof a + b
est interprété comme
(sizeof a) + b
parce que a+b n'est pas d'expression unaire.
-- Horst
Pierre Maurette
[...]
Soit la structure : struct toto { int a; long b; char c; };
Que renvoi un sizeof(toto) ? Et surtout... pourquoi ? :) Il n'y a pas moyen de le savoir de façon générale, seules certaines
contraintes de la norme et de l'implémentation permettent de le prévoir. Pour faire des tests:
typedef char t1; typedef short t2; typedef int t3;
(choisir t1, t2 et t3 pour avoir par exemple trois tailles différentes)
Les contraintes peuvent être:
- chaque élément de la structure a son propre alignement qu'il doit respecter dans la structure. Dans mon cas, sans autre paramétrage, chaque type simple est aligné sur sa propre taille. Pour les éléments structures, le raisonnement s'applique récursivement. - les éléments d'une structure sont implantés en mémoire dans l'ordre de la déclaration (à moins que la norme ne parle que du premier ?). - L'adresse de la structure est celle de son premier élément (= pas de padding initial). C'est je crois dans la norme. - On peut en déduire que la structure est au moins alignée comme son élément le plus contraint (et non comme le permier élément). On peut déjà connaître le padding entre élements. Reste le padding de fin. Il est calculé pour que la taille de la structure soit multiple de son alignement, puisque la norme doit bien dire quelque part qu'il n'y a pas de padding dans un tableau: sizeof(toto1[n]) == n * sizezof(struct toto1) -- Pierre
[...]
Soit la structure :
struct toto
{
int a;
long b;
char c;
};
Que renvoi un sizeof(toto) ? Et surtout... pourquoi ? :)
Il n'y a pas moyen de le savoir de façon générale, seules certaines
contraintes de la norme et de l'implémentation permettent de le prévoir.
Pour faire des tests:
typedef char t1;
typedef short t2;
typedef int t3;
(choisir t1, t2 et t3 pour avoir par exemple trois tailles différentes)
Les contraintes peuvent être:
- chaque élément de la structure a son propre alignement qu'il doit
respecter dans la structure. Dans mon cas, sans autre paramétrage,
chaque type simple est aligné sur sa propre taille. Pour les éléments
structures, le raisonnement s'applique récursivement.
- les éléments d'une structure sont implantés en mémoire dans l'ordre de
la déclaration (à moins que la norme ne parle que du premier ?).
- L'adresse de la structure est celle de son premier élément (= pas de
padding initial). C'est je crois dans la norme.
- On peut en déduire que la structure est au moins alignée comme son
élément le plus contraint (et non comme le permier élément). On peut
déjà connaître le padding entre élements. Reste le padding de fin. Il
est calculé pour que la taille de la structure soit multiple de son
alignement, puisque la norme doit bien dire quelque part qu'il n'y a pas
de padding dans un tableau:
sizeof(toto1[n]) == n * sizezof(struct toto1)
--
Pierre
(choisir t1, t2 et t3 pour avoir par exemple trois tailles différentes)
Les contraintes peuvent être:
- chaque élément de la structure a son propre alignement qu'il doit respecter dans la structure. Dans mon cas, sans autre paramétrage, chaque type simple est aligné sur sa propre taille. Pour les éléments structures, le raisonnement s'applique récursivement. - les éléments d'une structure sont implantés en mémoire dans l'ordre de la déclaration (à moins que la norme ne parle que du premier ?). - L'adresse de la structure est celle de son premier élément (= pas de padding initial). C'est je crois dans la norme. - On peut en déduire que la structure est au moins alignée comme son élément le plus contraint (et non comme le permier élément). On peut déjà connaître le padding entre élements. Reste le padding de fin. Il est calculé pour que la taille de la structure soit multiple de son alignement, puisque la norme doit bien dire quelque part qu'il n'y a pas de padding dans un tableau: sizeof(toto1[n]) == n * sizezof(struct toto1) -- Pierre
Jean-Noël Mégoz
"Nicolas" a écrit dans le message de news:41e6c552$0$12265$
Attention, sizeof n'est pas une fonction, (qui renvoie une valeur), mais un opérateur.
D'un point de vue conceptuel, c'est la même chose ! ;)
"Nicolas" <nicolas@none.com> a écrit dans le message de
news:41e6c552$0$12265$636a15ce@news.free.fr...
Attention, sizeof n'est pas une fonction, (qui renvoie une valeur), mais
un opérateur.
D'un point de vue conceptuel, c'est la même chose ! ;)
