comment sont organisées en mémoire les données membre d'une structure ?
par exemple si je déclare :
struct nom_s{
char *buffer1;
char *buffer2;
}
struct nom_s buf_s;
et qu'ensuite, dans mon code, je file l'adresse de cette structure a
une de mes fonctions, cette fonction est chargée d'enregistrer des
résultats dedans, et doit donc au préalable allouer de la mémoire pour
les buffer :
où sont dans la mémoire le buffer 1 et le buffer2 ? comment sont ils
placés, sachant qu'il doit bien y avoir quelque chose qui fait qu'ils
appartienent a la structure buf_s.
je pense que "l'architecture" du type est stockée (sa taille et son organisation).
comme les types primaires int, char, ect..
non?
Il est probable que, pour une architecture donnée, taille et organisation des types primaire soit fixe. Mais on peut imaginer un compilateur qui proposerait à l'utilisateur de choisir la taille des entiers comme option de compilation.
Mais après, il y a les types utilisateurs: enum et struct.
Marc Boyer -- Lying for having sex or lying for making war? Trust US presidents :-(
Bruno wrote:
je pense que "l'architecture" du type est stockée (sa taille et son
organisation).
comme les types primaires int, char, ect..
non?
Il est probable que, pour une architecture donnée, taille
et organisation des types primaire soit fixe.
Mais on peut imaginer un compilateur qui proposerait à l'utilisateur
de choisir la taille des entiers comme option de compilation.
Mais après, il y a les types utilisateurs: enum et struct.
Marc Boyer
--
Lying for having sex or lying for making war? Trust US presidents :-(
je pense que "l'architecture" du type est stockée (sa taille et son organisation).
comme les types primaires int, char, ect..
non?
Il est probable que, pour une architecture donnée, taille et organisation des types primaire soit fixe. Mais on peut imaginer un compilateur qui proposerait à l'utilisateur de choisir la taille des entiers comme option de compilation.
Mais après, il y a les types utilisateurs: enum et struct.
Marc Boyer -- Lying for having sex or lying for making war? Trust US presidents :-(
Serge Paccalin
Le jeudi 4 septembre 2003 à 17:07, Nicolas Aunai a écrit dans fr.comp.lang.c :
Qui connait la taille d'une variable ? Ben, sizeof te la donne.
hum, c pas vraiment ça que je voulais dire on s'est mal compris. dans le cas ou j'utilise une variable dans un code quelconque.
comment l'ordinateur sait-il où s'arreter dans la lecture de la varible pour retourner sa valeur ? avec son type ? genre un int il lira 4 octets...
C'est le compilateur qui le sait, et qui génère du code qui fait ce que tu lui demandes. Il le sait parce que son concepteur l' a écrit comme ça, avec les choix d'implantation en tête.
Le code final sait qu'il doit manipuler, disons, quatre octets parce que les instructions qui le composent sont câblées pour faire ça. Le code est composé de ces instructions-là parce que le compilateur a généré ces instructions-là. Le compilateur a généré ces instructions-là parce qu'il est écrit comme ça.
Par exemple, tu écris :
{ int i,j,k;
i = j + k; ...
et le compilateur choisit les positions (relatives ou absolues) des variables, puis génère du code qui manipule le bon nombre d'octets aux adresses choisies. Exemple Intel 32 bits :
« (1) Prends le contenu du registre ebp, soustrais 8, puis considère que c'est une adresse et recopie quatre octets à partir de cette adresse et mets-les dans le registre eax. « (2) Prends le contenu du registre ebp, soustrais 4, puis considère que c'est une adresse et recopie quatre octets à partir de cette adresse et ajoute-les dans le registre eax. « (3) Prends le contenu du registre ebp, soustrais 12 (0C hexa), puis considère que c'est une adresse et recopie le registre eax dans les quatre octets à partir de cette adresse. »
-- ___________ 2003-09-04 17:27:51 _/ _ _`_`_`_) Serge PACCALIN -- sp ad mailclub.net _L_) Il faut donc que les hommes commencent -'(__) par n'être pas fanatiques pour mériter _/___(_) la tolérance. -- Voltaire, 1763
Le jeudi 4 septembre 2003 à 17:07, Nicolas Aunai a écrit dans
fr.comp.lang.c :
Qui connait la taille d'une variable ? Ben, sizeof te la donne.
hum, c pas vraiment ça que je voulais dire on s'est mal compris.
dans le cas ou j'utilise une variable dans un code quelconque.
comment l'ordinateur sait-il où s'arreter dans la lecture de la varible
pour retourner sa valeur ? avec son type ? genre un int il lira 4
octets...
C'est le compilateur qui le sait, et qui génère du code qui fait ce que
tu lui demandes. Il le sait parce que son concepteur l' a écrit comme
ça, avec les choix d'implantation en tête.
Le code final sait qu'il doit manipuler, disons, quatre octets parce que
les instructions qui le composent sont câblées pour faire ça. Le code
est composé de ces instructions-là parce que le compilateur a généré ces
instructions-là. Le compilateur a généré ces instructions-là parce qu'il
est écrit comme ça.
Par exemple, tu écris :
{
int i,j,k;
i = j + k;
...
et le compilateur choisit les positions (relatives ou absolues) des
variables, puis génère du code qui manipule le bon nombre d'octets aux
adresses choisies. Exemple Intel 32 bits :
« (1) Prends le contenu du registre ebp, soustrais 8, puis considère que
c'est une adresse et recopie quatre octets à partir de cette adresse et
mets-les dans le registre eax.
« (2) Prends le contenu du registre ebp, soustrais 4, puis considère que
c'est une adresse et recopie quatre octets à partir de cette adresse et
ajoute-les dans le registre eax.
« (3) Prends le contenu du registre ebp, soustrais 12 (0C hexa), puis
considère que c'est une adresse et recopie le registre eax dans les
quatre octets à partir de cette adresse. »
--
___________ 2003-09-04 17:27:51
_/ _ _`_`_`_) Serge PACCALIN -- sp ad mailclub.net
_L_) Il faut donc que les hommes commencent
-'(__) par n'être pas fanatiques pour mériter
_/___(_) la tolérance. -- Voltaire, 1763
Le jeudi 4 septembre 2003 à 17:07, Nicolas Aunai a écrit dans fr.comp.lang.c :
Qui connait la taille d'une variable ? Ben, sizeof te la donne.
hum, c pas vraiment ça que je voulais dire on s'est mal compris. dans le cas ou j'utilise une variable dans un code quelconque.
comment l'ordinateur sait-il où s'arreter dans la lecture de la varible pour retourner sa valeur ? avec son type ? genre un int il lira 4 octets...
C'est le compilateur qui le sait, et qui génère du code qui fait ce que tu lui demandes. Il le sait parce que son concepteur l' a écrit comme ça, avec les choix d'implantation en tête.
Le code final sait qu'il doit manipuler, disons, quatre octets parce que les instructions qui le composent sont câblées pour faire ça. Le code est composé de ces instructions-là parce que le compilateur a généré ces instructions-là. Le compilateur a généré ces instructions-là parce qu'il est écrit comme ça.
Par exemple, tu écris :
{ int i,j,k;
i = j + k; ...
et le compilateur choisit les positions (relatives ou absolues) des variables, puis génère du code qui manipule le bon nombre d'octets aux adresses choisies. Exemple Intel 32 bits :
« (1) Prends le contenu du registre ebp, soustrais 8, puis considère que c'est une adresse et recopie quatre octets à partir de cette adresse et mets-les dans le registre eax. « (2) Prends le contenu du registre ebp, soustrais 4, puis considère que c'est une adresse et recopie quatre octets à partir de cette adresse et ajoute-les dans le registre eax. « (3) Prends le contenu du registre ebp, soustrais 12 (0C hexa), puis considère que c'est une adresse et recopie le registre eax dans les quatre octets à partir de cette adresse. »
-- ___________ 2003-09-04 17:27:51 _/ _ _`_`_`_) Serge PACCALIN -- sp ad mailclub.net _L_) Il faut donc que les hommes commencent -'(__) par n'être pas fanatiques pour mériter _/___(_) la tolérance. -- Voltaire, 1763
Bruno
dans l'article 136pii7rrct4s$, Serge Paccalin à a écrit le 04/09/2003 17:41 :
C'est le compilateur qui le sait, et qui génère du code qui fait ce que tu lui demandes. Il le sait parce que son concepteur l' a écrit comme ça, avec les choix d'implantation en tête.
mais bien sur :)
-- Bruno Causse http://perso.wanadoo.fr/othello
dans l'article 136pii7rrct4s$.dlg@canttouchthis-127.0.0.1, Serge Paccalin à
sp@mailclub.no.spam.net.invalid a écrit le 04/09/2003 17:41 :
C'est le compilateur qui le sait, et qui génère du code qui fait ce que
tu lui demandes. Il le sait parce que son concepteur l' a écrit comme
ça, avec les choix d'implantation en tête.
dans l'article 136pii7rrct4s$, Serge Paccalin à a écrit le 04/09/2003 17:41 :
C'est le compilateur qui le sait, et qui génère du code qui fait ce que tu lui demandes. Il le sait parce que son concepteur l' a écrit comme ça, avec les choix d'implantation en tête.
mais bien sur :)
-- Bruno Causse http://perso.wanadoo.fr/othello
AG
Nicolas Aunai wrote:
comment sont orgranisées les données en mémoire précisément ? j'veux dire, la structure, c un truc qui "englobe" des variables... si on veut accéder a un de ses membres on doit préciser tout d'abords le nom de la structure, comment cela est-il représenté dans la mémoire ? comment l'ordinateur sait-il que telle zone mémoire est sous la dépendance d'une structure et non une variable quelconque ?
Il est temps d'aller voir comment fonctionne un débugger. ça permet entre autre de voir l'état de la mémoire, et de constater comment sont ranger les structures en mémoire.
Nicolas Aunai wrote:
comment sont orgranisées les données en mémoire précisément ?
j'veux dire, la structure, c un truc qui "englobe" des variables... si
on veut accéder a un de ses membres on doit préciser tout d'abords le
nom de la structure, comment cela est-il représenté dans la mémoire ?
comment l'ordinateur sait-il que telle zone mémoire est sous la
dépendance d'une structure et non une variable quelconque ?
Il est temps d'aller voir comment fonctionne un débugger. ça permet
entre autre de voir l'état de la mémoire, et de constater comment sont
ranger les structures en mémoire.
comment sont orgranisées les données en mémoire précisément ? j'veux dire, la structure, c un truc qui "englobe" des variables... si on veut accéder a un de ses membres on doit préciser tout d'abords le nom de la structure, comment cela est-il représenté dans la mémoire ? comment l'ordinateur sait-il que telle zone mémoire est sous la dépendance d'une structure et non une variable quelconque ?
Il est temps d'aller voir comment fonctionne un débugger. ça permet entre autre de voir l'état de la mémoire, et de constater comment sont ranger les structures en mémoire.
AG
il me semble que la question etait comment et ou est stocké "l'architecture" d'une structure ex :un int suivi d'un char puis d'un pointeur etc
puis par approfondissement
un int = 4 ou + octets char = 1 ou + pointeur...
et donc ? quel est le problème avec le débugger ?
il me semble que la question etait comment et ou est stocké "l'architecture"
d'une structure
ex :un int suivi d'un char puis d'un pointeur etc
il me semble que la question etait comment et ou est stocké "l'architecture" d'une structure ex :un int suivi d'un char puis d'un pointeur etc
puis par approfondissement
un int = 4 ou + octets char = 1 ou + pointeur...
et donc ? quel est le problème avec le débugger ?
Emmanuel Delahaye
In 'fr.comp.lang.c', Nicolas Aunai @free.fr> wrote:
salut !
comment sont organisées en mémoire les données membre d'une structure ? par exemple si je déclare :
- Le premier élément défini est à l'adresse de la structure - L'ordre est le même que celui qui est défini. C'est tout ce qui est défini par la norme. Le reste (padding, notamment) est à la discrétion de l'implémentation.
struct nom_s{
char *buffer1; char *buffer2; }
struct nom_s buf_s;
et qu'ensuite, dans mon code, je file l'adresse de cette structure a une de mes fonctions, cette fonction est chargée d'enregistrer des résultats dedans, et doit donc au préalable allouer de la mémoire pour les buffer :
où sont dans la mémoire le buffer 1 et le buffer2 ?
Les buffers 1 et 2 qui sont alloués dynamiquement se trouvent n'importe où en mémoire.
comment sont ils placés, sachant qu'il doit bien y avoir quelque chose qui fait qu'ils appartienent a la structure buf_s.
Ta structure comportant au moins un pointeur, elle est dite 'non-linéaire'. Seules les /adresses/ de ces buffers sont stockés dans la structure.
C'est pareil avec
char *s = "hello world";
La chaine se trouve à un endroit qui peut être complément différent de 's'.
-- -ed- [remove YOURBRA before answering me] The C-language FAQ: http://www.eskimo.com/~scs/C-faq/top.html <blank line> FAQ de f.c.l.c : http://www.isty-info.uvsq.fr/~rumeau/fclc/
In 'fr.comp.lang.c', Nicolas Aunai <nicolas.aunai@nospam@free.fr> wrote:
salut !
comment sont organisées en mémoire les données membre d'une structure ?
par exemple si je déclare :
- Le premier élément défini est à l'adresse de la structure
- L'ordre est le même que celui qui est défini.
C'est tout ce qui est défini par la norme. Le reste (padding, notamment) est
à la discrétion de l'implémentation.
struct nom_s{
char *buffer1;
char *buffer2;
}
struct nom_s buf_s;
et qu'ensuite, dans mon code, je file l'adresse de cette structure a
une de mes fonctions, cette fonction est chargée d'enregistrer des
résultats dedans, et doit donc au préalable allouer de la mémoire pour
les buffer :
In 'fr.comp.lang.c', Nicolas Aunai @free.fr> wrote:
salut !
comment sont organisées en mémoire les données membre d'une structure ? par exemple si je déclare :
- Le premier élément défini est à l'adresse de la structure - L'ordre est le même que celui qui est défini. C'est tout ce qui est défini par la norme. Le reste (padding, notamment) est à la discrétion de l'implémentation.
struct nom_s{
char *buffer1; char *buffer2; }
struct nom_s buf_s;
et qu'ensuite, dans mon code, je file l'adresse de cette structure a une de mes fonctions, cette fonction est chargée d'enregistrer des résultats dedans, et doit donc au préalable allouer de la mémoire pour les buffer :
-- -ed- [remove YOURBRA before answering me] The C-language FAQ: http://www.eskimo.com/~scs/C-faq/top.html <blank line> FAQ de f.c.l.c : http://www.isty-info.uvsq.fr/~rumeau/fclc/
Emmanuel Delahaye
In 'fr.comp.lang.c', Nicolas Aunai @free.fr> wrote:
comment sont orgranisées les données en mémoire précisément ?
Ca dépend de l'implémentation.
j'veux dire, la structure, c un truc qui "englobe" des variables... si on veut accéder a un de ses membres on doit préciser tout d'abords le nom de la structure, comment cela est-il représenté dans la mémoire ? comment l'ordinateur sait-il que telle zone mémoire est sous la dépendance d'une structure et non une variable quelconque ?
Il n'en sait rien. Souvent le codage en langage machine utilise des modes d'adressages 'basés'. L'adresse d'un élément est l'adresse de la la base + un offset. L'adresse de la base est par exemple l'adresse de la structure. L'offset est par exemple le nombre de bytes qui sépare la base de l'élément.
C'est une constante que connait le compilateur (résultat de la macro standard offsetof()). Il est donc capable de mettre la valeur qui va bien, en laissant l'instruction faire le calcul qui va bien pour atteindre et déférencer la donnée.
Si ces détails t'interessent (inutile en C, mais utile pour la culture générale), je te conseille d'étudier le langage assembleur de ton implémentatrion et d'aller voir le code généré. (Souvent, une option de compilaton permet de conserver le code assembleur produit par le compilateur).
-- -ed- [remove YOURBRA before answering me] The C-language FAQ: http://www.eskimo.com/~scs/C-faq/top.html <blank line> FAQ de f.c.l.c : http://www.isty-info.uvsq.fr/~rumeau/fclc/
In 'fr.comp.lang.c', Nicolas Aunai <nicolas.aunai@nospam@free.fr> wrote:
comment sont orgranisées les données en mémoire précisément ?
Ca dépend de l'implémentation.
j'veux dire, la structure, c un truc qui "englobe" des variables... si
on veut accéder a un de ses membres on doit préciser tout d'abords le
nom de la structure, comment cela est-il représenté dans la mémoire ?
comment l'ordinateur sait-il que telle zone mémoire est sous la
dépendance d'une structure et non une variable quelconque ?
Il n'en sait rien. Souvent le codage en langage machine utilise des modes
d'adressages 'basés'. L'adresse d'un élément est l'adresse de la la base + un
offset. L'adresse de la base est par exemple l'adresse de la structure.
L'offset est par exemple le nombre de bytes qui sépare la base de l'élément.
C'est une constante que connait le compilateur (résultat de la
macro standard offsetof()). Il est donc capable de mettre la valeur qui va
bien, en laissant l'instruction faire le calcul qui va bien pour atteindre
et déférencer la donnée.
Si ces détails t'interessent (inutile en C, mais utile pour la culture
générale), je te conseille d'étudier le langage assembleur de ton
implémentatrion et d'aller voir le code généré. (Souvent, une option de
compilaton permet de conserver le code assembleur produit par le
compilateur).
--
-ed- emdelYOURBRA@noos.fr [remove YOURBRA before answering me]
The C-language FAQ: http://www.eskimo.com/~scs/C-faq/top.html
<blank line>
FAQ de f.c.l.c : http://www.isty-info.uvsq.fr/~rumeau/fclc/
In 'fr.comp.lang.c', Nicolas Aunai @free.fr> wrote:
comment sont orgranisées les données en mémoire précisément ?
Ca dépend de l'implémentation.
j'veux dire, la structure, c un truc qui "englobe" des variables... si on veut accéder a un de ses membres on doit préciser tout d'abords le nom de la structure, comment cela est-il représenté dans la mémoire ? comment l'ordinateur sait-il que telle zone mémoire est sous la dépendance d'une structure et non une variable quelconque ?
Il n'en sait rien. Souvent le codage en langage machine utilise des modes d'adressages 'basés'. L'adresse d'un élément est l'adresse de la la base + un offset. L'adresse de la base est par exemple l'adresse de la structure. L'offset est par exemple le nombre de bytes qui sépare la base de l'élément.
C'est une constante que connait le compilateur (résultat de la macro standard offsetof()). Il est donc capable de mettre la valeur qui va bien, en laissant l'instruction faire le calcul qui va bien pour atteindre et déférencer la donnée.
Si ces détails t'interessent (inutile en C, mais utile pour la culture générale), je te conseille d'étudier le langage assembleur de ton implémentatrion et d'aller voir le code généré. (Souvent, une option de compilaton permet de conserver le code assembleur produit par le compilateur).
-- -ed- [remove YOURBRA before answering me] The C-language FAQ: http://www.eskimo.com/~scs/C-faq/top.html <blank line> FAQ de f.c.l.c : http://www.isty-info.uvsq.fr/~rumeau/fclc/
Emmanuel Delahaye
In 'fr.comp.lang.c', Nicolas Aunai @free.fr> wrote:
comment l'ordinateur sait-il où s'arreter dans la lecture de la varible pour retourner sa valeur ? avec son type ? genre un int il lira 4 octets...
Oui. Par exemple un 68000 connait les types natifs .B (BYTE : 8-bit), .W (WORD : 16-bit) et .L (long : 32-bit),
En fonction du type, le code généré sera différent :
{ char x = 1; /* MOVE.B #1, D0 */ short y = 2; /* MOVE.W #2, D1 */ int z = 3; /* MOVE.L #3, D2 */ long t = 4; /* MOVE.L #4, D3 */ }
(Je ne suis pas très sûr du '#', il y a longtemps que je n'ai pas fait de 68000)
-- -ed- [remove YOURBRA before answering me] The C-language FAQ: http://www.eskimo.com/~scs/C-faq/top.html <blank line> FAQ de f.c.l.c : http://www.isty-info.uvsq.fr/~rumeau/fclc/
In 'fr.comp.lang.c', Nicolas Aunai <nicolas.aunai@nospam@free.fr> wrote:
comment l'ordinateur sait-il où s'arreter dans la lecture de la varible
pour retourner sa valeur ? avec son type ? genre un int il lira 4
octets...
Oui. Par exemple un 68000 connait les types natifs .B (BYTE : 8-bit), .W
(WORD : 16-bit) et .L (long : 32-bit),
En fonction du type, le code généré sera différent :
{
char x = 1; /* MOVE.B #1, D0 */
short y = 2; /* MOVE.W #2, D1 */
int z = 3; /* MOVE.L #3, D2 */
long t = 4; /* MOVE.L #4, D3 */
}
(Je ne suis pas très sûr du '#', il y a longtemps que je n'ai pas fait de
68000)
--
-ed- emdelYOURBRA@noos.fr [remove YOURBRA before answering me]
The C-language FAQ: http://www.eskimo.com/~scs/C-faq/top.html
<blank line>
FAQ de f.c.l.c : http://www.isty-info.uvsq.fr/~rumeau/fclc/
