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.
Ca ne fait que modifier le code produit. Rien de magique. Le processeur se contente de faire ce qu'on lui dit de faire. Point.
Mais après, il y a les types utilisateurs: enum et struct.
Les enums ne sont de de simples constantes (valeurs immédiates). Les structures sont des agrégats de données accessibles par le couple base + offset. Rien de magique. Ensuite, le type détermine l'usage de la bonne instruction ou du groupe d'instruction nécessaire à l'accès si celui-ci n'est pas basique.
-- -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', Marc Boyer <Marc.Boyer@enseeiht.yahoo.fr> 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.
Ca ne fait que modifier le code produit. Rien de magique. Le processeur se
contente de faire ce qu'on lui dit de faire. Point.
Mais après, il y a les types utilisateurs: enum et struct.
Les enums ne sont de de simples constantes (valeurs immédiates). Les
structures sont des agrégats de données accessibles par le couple base +
offset. Rien de magique. Ensuite, le type détermine l'usage de la bonne
instruction ou du groupe d'instruction nécessaire à l'accès si celui-ci n'est
pas basique.
--
-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/
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.
Ca ne fait que modifier le code produit. Rien de magique. Le processeur se contente de faire ce qu'on lui dit de faire. Point.
Mais après, il y a les types utilisateurs: enum et struct.
Les enums ne sont de de simples constantes (valeurs immédiates). Les structures sont des agrégats de données accessibles par le couple base + offset. Rien de magique. Ensuite, le type détermine l'usage de la bonne instruction ou du groupe d'instruction nécessaire à l'accès si celui-ci n'est pas basique.
-- -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', Bruno wrote:
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 :)
Ben oui. Si tu as une remarque à faire, soit plus précis.
-- -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', Bruno <bcausse@lepoint.tm.fr> wrote:
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.
mais bien sur :)
Ben oui. Si tu as une remarque à faire, soit plus précis.
--
-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/
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 :)
Ben oui. Si tu as une remarque à faire, soit plus précis.
-- -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', Bruno wrote:
il me semble que la question etait comment et ou est stocké "l'architecture" d'une structure
Elle n'est pas stockée explicitement. Elle est connue du compilateur qui ecrit le code assembleur (ou machine) qui va bien pour accéder à la donnée.
ex :un int suivi d'un char puis d'un pointeur etc
puis par approfondissement
un int = 4 ou + octets char = 1 ou + pointeur...
-- -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', Bruno <bcausse@lepoint.tm.fr> wrote:
il me semble que la question etait comment et ou est stocké
"l'architecture" d'une structure
Elle n'est pas stockée explicitement. Elle est connue du compilateur qui
ecrit le code assembleur (ou machine) qui va bien pour accéder à la donnée.
ex :un int suivi d'un char puis d'un pointeur etc
puis par approfondissement
un int = 4 ou + octets
char = 1 ou +
pointeur...
--
-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/
il me semble que la question etait comment et ou est stocké "l'architecture" d'une structure
Elle n'est pas stockée explicitement. Elle est connue du compilateur qui ecrit le code assembleur (ou machine) qui va bien pour accéder à la donnée.
ex :un int suivi d'un char puis d'un pointeur etc
puis par approfondissement
un int = 4 ou + octets char = 1 ou + pointeur...
-- -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/
Nicolas Aunai
ok merci a tous pour ces explications !
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).
hum... pas bcp de temps pour l'assembleur, bien que ce soient encore les vacances pour moi.. pas que ça a faire, c'était juste de la curiosité.
-- Nico, http://astrosurf.com/nicoastro
ok merci a tous pour ces explications !
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).
hum... pas bcp de temps pour l'assembleur, bien que ce soient encore
les vacances pour moi.. pas que ça a faire, c'était juste de la
curiosité.
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).
hum... pas bcp de temps pour l'assembleur, bien que ce soient encore les vacances pour moi.. pas que ça a faire, c'était juste de la curiosité.
-- Nico, http://astrosurf.com/nicoastro
Dominique Baldo
Nicolas Aunai nous disait
hum... pas bcp de temps pour l'assembleur, bien que ce soient encore les vacances pour moi.. pas que ça a faire, c'était juste de la curiosité.
On peut faire du C et comprendre les pointeurs, les tableaux et autres sans avoir fait d'assembleur ... mais ça aide bien d'en avoir fait.
Nicolas Aunai nous disait
hum... pas bcp de temps pour l'assembleur, bien que ce soient encore
les vacances pour moi.. pas que ça a faire, c'était juste de la
curiosité.
On peut faire du C et comprendre les pointeurs, les tableaux et autres
sans avoir fait d'assembleur ... mais ça aide bien d'en avoir fait.
hum... pas bcp de temps pour l'assembleur, bien que ce soient encore les vacances pour moi.. pas que ça a faire, c'était juste de la curiosité.
On peut faire du C et comprendre les pointeurs, les tableaux et autres sans avoir fait d'assembleur ... mais ça aide bien d'en avoir fait.
Tout à fait. Ca concrétise les choses, et ça évite de phantasmer.
-- -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/
Bertrand Mollinier Toublet
Nicolas Aunai wrote:
"Stephane Legras-Decussy" a utilisé son clavier pour écrire :
du point de vue du C, j'aurais envie de te dire "qu'est que ça peut te faire ?"
pourquoi tu veux savoir ça ? car ce n'est plus du C ...
du point de vue de la culture informatique, ok, tu peux te poser la question... mais c'est HS ... ;-)
hum... ça a pourtant l'air d'etre du C, les structures, les pointeurs, les allocations, la fonction malloc etc... tout ça fait partie du C, et si je veux savoir, c'est par curiosité :)
bon j'ai pigé qu'en fait la structure contient deux pointeurs, j'aurai pu y penser moi meme, ce sont des pointeurs, donc ont juste l'adresse de la mémoire allouée... la taille de la structure reste inchangée...
j'insiste encore un peu alors, dans ce pseudo HS (si pas là, dites moi ou poster)
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 ?
Ne t'y meprends pas: les structures ne sont qu'un artifice semantique du
langage. Par exemple, sur une architecture Intel (juste pour ne pas dire "en general", afin d'exclure la DS9000), une fois ton code compile, la machine n'a aucune idee de qui est une strucure ou quoi. Tout se passe en terme d'acces au bon endroit en memoire. C'est au moment de la compilation que ton compilateur va transformer la syntaxe de structure (x.y ou px->y) en acces au bon endroit en memoire...
"Stephane Legras-Decussy" a utilisé son clavier pour écrire :
du point de vue du C,
j'aurais envie de te dire "qu'est que ça peut te faire ?"
pourquoi tu veux savoir ça ? car ce n'est plus du C ...
du point de vue de la culture informatique, ok, tu peux te poser
la question... mais c'est HS ... ;-)
hum... ça a pourtant l'air d'etre du C, les structures, les pointeurs,
les allocations, la fonction malloc etc... tout ça fait partie du C, et
si je veux savoir, c'est par curiosité :)
bon j'ai pigé qu'en fait la structure contient deux pointeurs, j'aurai
pu y penser moi meme, ce sont des pointeurs, donc ont juste l'adresse de
la mémoire allouée... la taille de la structure reste inchangée...
j'insiste encore un peu alors, dans ce pseudo HS (si pas là, dites moi
ou poster)
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 ?
Ne t'y meprends pas: les structures ne sont qu'un artifice semantique du
langage. Par exemple, sur une architecture Intel (juste pour ne pas dire
"en general", afin d'exclure la DS9000), une fois ton code compile, la
machine n'a aucune idee de qui est une strucure ou quoi. Tout se passe
en terme d'acces au bon endroit en memoire. C'est au moment de la
compilation que ton compilateur va transformer la syntaxe de structure
(x.y ou px->y) en acces au bon endroit en memoire...
"Stephane Legras-Decussy" a utilisé son clavier pour écrire :
du point de vue du C, j'aurais envie de te dire "qu'est que ça peut te faire ?"
pourquoi tu veux savoir ça ? car ce n'est plus du C ...
du point de vue de la culture informatique, ok, tu peux te poser la question... mais c'est HS ... ;-)
hum... ça a pourtant l'air d'etre du C, les structures, les pointeurs, les allocations, la fonction malloc etc... tout ça fait partie du C, et si je veux savoir, c'est par curiosité :)
bon j'ai pigé qu'en fait la structure contient deux pointeurs, j'aurai pu y penser moi meme, ce sont des pointeurs, donc ont juste l'adresse de la mémoire allouée... la taille de la structure reste inchangée...
j'insiste encore un peu alors, dans ce pseudo HS (si pas là, dites moi ou poster)
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 ?
Ne t'y meprends pas: les structures ne sont qu'un artifice semantique du
langage. Par exemple, sur une architecture Intel (juste pour ne pas dire "en general", afin d'exclure la DS9000), une fois ton code compile, la machine n'a aucune idee de qui est une strucure ou quoi. Tout se passe en terme d'acces au bon endroit en memoire. C'est au moment de la compilation que ton compilateur va transformer la syntaxe de structure (x.y ou px->y) en acces au bon endroit en memoire...
"Bertrand Mollinier Toublet" a exposé le 05/09/2003 :
Ne t'y meprends pas: les structures ne sont qu'un artifice semantique du langage. Par exemple, sur une architecture Intel (juste pour ne pas dire "en general", afin d'exclure la DS9000), une fois ton code compile, la machine n'a aucune idee de qui est une strucure ou quoi. Tout se passe en terme d'acces au bon endroit en memoire. C'est au moment de la compilation que ton compilateur va transformer la syntaxe de structure (x.y ou px->y) en acces au bon endroit en memoire...
je m'en doutais un peu... cependant le C est un langage avec tout de même plus de transparance pour ce qui se passe en mémoire qu'un langage de plus haut niveau, alors forcément, ça éveille la curiosité :)
-- Nico, http://astrosurf.com/nicoastro
"Bertrand Mollinier Toublet" a exposé le 05/09/2003 :
Ne t'y meprends pas: les structures ne sont qu'un artifice semantique du
langage. Par exemple, sur une architecture Intel (juste pour ne pas dire "en
general", afin d'exclure la DS9000), une fois ton code compile, la machine
n'a aucune idee de qui est une strucure ou quoi. Tout se passe en terme
d'acces au bon endroit en memoire. C'est au moment de la compilation que ton
compilateur va transformer la syntaxe de structure (x.y ou px->y) en acces au
bon endroit en memoire...
je m'en doutais un peu... cependant le C est un langage avec tout de
même plus de transparance pour ce qui se passe en mémoire qu'un langage
de plus haut niveau, alors forcément, ça éveille la curiosité :)
"Bertrand Mollinier Toublet" a exposé le 05/09/2003 :
Ne t'y meprends pas: les structures ne sont qu'un artifice semantique du langage. Par exemple, sur une architecture Intel (juste pour ne pas dire "en general", afin d'exclure la DS9000), une fois ton code compile, la machine n'a aucune idee de qui est une strucure ou quoi. Tout se passe en terme d'acces au bon endroit en memoire. C'est au moment de la compilation que ton compilateur va transformer la syntaxe de structure (x.y ou px->y) en acces au bon endroit en memoire...
je m'en doutais un peu... cependant le C est un langage avec tout de même plus de transparance pour ce qui se passe en mémoire qu'un langage de plus haut niveau, alors forcément, ça éveille la curiosité :)
-- Nico, http://astrosurf.com/nicoastro
Marc Boyer
Emmanuel Delahaye wrote:
In 'fr.comp.lang.c', Marc Boyer wrote:
je pense que "l'architecture" du type est stockée (sa taille et son organisation).
comme les types primaires int, char, ect..
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.
Ca ne fait que modifier le code produit. Rien de magique. Le processeur se contente de faire ce qu'on lui dit de faire. Point.
Ce n'est pas magique en effet (ceci dit, j'espère bien que de manière générale, il y a peu de magie dans ma machine). C'était juste pour dire que l'architecture du type n'était pas forcément fixe. Ceci dit, en y réfléchissant après une bonne nuit de sommeil, l'existence d'une ABI doit limiter quand même les variations. Puisque l'ABI implique qu'on puisse lier des sources compilés avec deux compilateurs différents, la taille des types de base doit être fixée pour une plateforme donnée.
Mais après, il y a les types utilisateurs: enum et struct.
Les enums ne sont de de simples constantes (valeurs immédiates). Les structures sont des agrégats de données accessibles par le couple base + offset. Rien de magique. Ensuite, le type détermine l'usage de la bonne instruction ou du groupe d'instruction nécessaire à l'accès si celui-ci n'est pas basique.
Voui, mais le calcul de l'offset est laissé à la charge du compilateur, qui définit le "padding" qui lui semble optimal, non ? Ce que je n'arrive pas à voir (et qui doit surement être écrit quelque part), c'est si on peut lier deux codes qui manipulent les mêmes structures mais compilés avec des règles de padding différentes.
Marc Boyer -- Lying for having sex or lying for making war? Trust US presidents :-(
Emmanuel Delahaye wrote:
In 'fr.comp.lang.c', Marc Boyer <Marc.Boyer@enseeiht.yahoo.fr> wrote:
je pense que "l'architecture" du type est stockée (sa taille et son
organisation).
comme les types primaires int, char, ect..
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.
Ca ne fait que modifier le code produit. Rien de magique. Le processeur se
contente de faire ce qu'on lui dit de faire. Point.
Ce n'est pas magique en effet (ceci dit, j'espère bien que
de manière générale, il y a peu de magie dans ma machine).
C'était juste pour dire que l'architecture du type
n'était pas forcément fixe.
Ceci dit, en y réfléchissant après une bonne nuit de sommeil,
l'existence d'une ABI doit limiter quand même les variations.
Puisque l'ABI implique qu'on puisse lier des sources compilés
avec deux compilateurs différents, la taille des types de
base doit être fixée pour une plateforme donnée.
Mais après, il y a les types utilisateurs: enum et struct.
Les enums ne sont de de simples constantes (valeurs immédiates). Les
structures sont des agrégats de données accessibles par le couple base +
offset. Rien de magique. Ensuite, le type détermine l'usage de la bonne
instruction ou du groupe d'instruction nécessaire à l'accès si celui-ci n'est
pas basique.
Voui, mais le calcul de l'offset est laissé à la charge du compilateur,
qui définit le "padding" qui lui semble optimal, non ?
Ce que je n'arrive pas à voir (et qui doit surement être écrit
quelque part), c'est si on peut lier deux codes qui manipulent
les mêmes structures mais compilés avec des règles de padding différentes.
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..
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.
Ca ne fait que modifier le code produit. Rien de magique. Le processeur se contente de faire ce qu'on lui dit de faire. Point.
Ce n'est pas magique en effet (ceci dit, j'espère bien que de manière générale, il y a peu de magie dans ma machine). C'était juste pour dire que l'architecture du type n'était pas forcément fixe. Ceci dit, en y réfléchissant après une bonne nuit de sommeil, l'existence d'une ABI doit limiter quand même les variations. Puisque l'ABI implique qu'on puisse lier des sources compilés avec deux compilateurs différents, la taille des types de base doit être fixée pour une plateforme donnée.
Mais après, il y a les types utilisateurs: enum et struct.
Les enums ne sont de de simples constantes (valeurs immédiates). Les structures sont des agrégats de données accessibles par le couple base + offset. Rien de magique. Ensuite, le type détermine l'usage de la bonne instruction ou du groupe d'instruction nécessaire à l'accès si celui-ci n'est pas basique.
Voui, mais le calcul de l'offset est laissé à la charge du compilateur, qui définit le "padding" qui lui semble optimal, non ? Ce que je n'arrive pas à voir (et qui doit surement être écrit quelque part), c'est si on peut lier deux codes qui manipulent les mêmes structures mais compilés avec des règles de padding différentes.
Marc Boyer -- Lying for having sex or lying for making war? Trust US presidents :-(
Gabriel Dos Reis
Emmanuel Delahaye writes:
| Tout à fait. Ca concrétise les choses, et ça évite de phantasmer. ^^
Vraiment ? ;-)
-- Gaby
Emmanuel Delahaye <emdelYOURBRA@noos.fr> writes:
| Tout à fait. Ca concrétise les choses, et ça évite de phantasmer.
^^
