Mais je veux que somme garde une variable en m=E9moire, donc j'utilise
un type static
ex (vraiment juste pour l'exemple):
somme(int i)
{
static z=3D0;
z+=3Di;
}
Cependant je veux que ces variables statiques soient diff=E9rentes pour
toutes mes fonctions de tabFunc.
Ai-je le droit de faire quelque chose du genre
Merci (je n'ai pas test=E9 j'aimerais surtout savoir si il y a une
erreur dans mon raisonnement qui me parait correct, et je n'ai rien
trouv=E9 l=E0 dessus encore sur le net)
Ok je suis peut être ignorant, mais une variable static est quelque part en ram? Enfin en tout cas dans la mémoire heap.
Il me semble que le tas (heap) et la zone statique (static) sont deux zones différentes de l'espace mémoire virtuel d'un processus. Peut-être est-ce différent d'un système à un autre.
Ce qui n'a rien à voir avec votre discours, je sais.
Okerampa wrote:
Ok je suis peut être ignorant, mais une variable static est quelque
part en ram? Enfin en tout cas dans la mémoire heap.
Il me semble que le tas (heap) et la zone statique (static) sont
deux zones différentes de l'espace mémoire virtuel d'un processus.
Peut-être est-ce différent d'un système à un autre.
Ce qui n'a rien à voir avec votre discours, je sais.
Ok je suis peut être ignorant, mais une variable static est quelque part en ram? Enfin en tout cas dans la mémoire heap.
Il me semble que le tas (heap) et la zone statique (static) sont deux zones différentes de l'espace mémoire virtuel d'un processus. Peut-être est-ce différent d'un système à un autre.
Ce qui n'a rien à voir avec votre discours, je sais.
Stephane Zuckerman
Finalement j'ai pris la solution de passer en argument, mais imaginons que je mette un compteur dans ma fonction, je suis obligé d'utiliser cette ruse de passage par argument.
D'un autre côté au moins, il n'y a pas d'effet de bord indésiré. Celui qui utilise votre fonction sans savoir qu'il existe une variable déclarée static à l'intérieur pourrait bien avoir des surprises dans certains cas ...
-- "Je deteste les ordinateurs : ils font toujours ce que je dis, jamais ce que je veux !" "The obvious mathematical breakthrough would be development of an easy way to factor large prime numbers." (Bill Gates, The Road Ahead)
Finalement j'ai pris la solution de passer en argument, mais imaginons
que je mette un compteur dans ma fonction, je suis obligé d'utiliser
cette ruse de passage par argument.
D'un autre côté au moins, il n'y a pas d'effet de bord indésiré. Celui qui
utilise votre fonction sans savoir qu'il existe une variable déclarée
static à l'intérieur pourrait bien avoir des surprises dans certains cas
...
--
"Je deteste les ordinateurs : ils font toujours ce que je dis, jamais ce
que je veux !"
"The obvious mathematical breakthrough would be development of an easy
way to factor large prime numbers." (Bill Gates, The Road Ahead)
Finalement j'ai pris la solution de passer en argument, mais imaginons que je mette un compteur dans ma fonction, je suis obligé d'utiliser cette ruse de passage par argument.
D'un autre côté au moins, il n'y a pas d'effet de bord indésiré. Celui qui utilise votre fonction sans savoir qu'il existe une variable déclarée static à l'intérieur pourrait bien avoir des surprises dans certains cas ...
-- "Je deteste les ordinateurs : ils font toujours ce que je dis, jamais ce que je veux !" "The obvious mathematical breakthrough would be development of an easy way to factor large prime numbers." (Bill Gates, The Road Ahead)
Ok je suis peut être ignorant, mais une variable static est quelque part en ram? Enfin en tout cas dans la mémoire heap.
Oui, elle est quelque part. Mais généralement pas au même endroit que le code.
De là, il est entièrement possible de créer un code assembleur de la fonction copié (la même, mais copiée, comme on copie en C++ avec un constructeur par recopie), mais de prendre pour variable static aussi des copies des variables?
Sauf que dans le code compilé, je ne pense pas qu'on fasse aucune différence entre une variable globale et une variable statique. Creer une nouvelle instance de la fonction qui gère cette différence, pas facile. De toute façon, ça ne serait pas un simple "memcpy" mais une fonction particulière (genre "fctcpy"). Et ça suppose qu'on aille créer synamiquement du code. En plus, ce serait assez inefficace: pour s'éviter un passage de paramètre d'aller recopier tout le code exécutable. Pour finir, en C++, ben, il y a un paramêtre caché "this" aux appels de méthodes membres.
D'où ma question sur le _inline qui est a ma connaissance une copie du code de la fonction.
Mais qui se fait à la compilation, pas à l'exécution.
Parce que je n'ai pas testé, mais je suppose que deux pointeurs de fonction qui pointent sur la même fonction partagent le static (je ne me trompe pas, là?)
Oui.
Finalement j'ai pris la solution de passer en argument, mais imaginons que je mette un compteur dans ma fonction, je suis obligé d'utiliser cette ruse de passage par argument.
Oui.
Marc Boyer -- Je ne respecte plus le code de la route à vélo depuis une double fracture due au fait que j'étais le seul à le respecter.
Ok je suis peut être ignorant, mais une variable static est quelque
part en ram? Enfin en tout cas dans la mémoire heap.
Oui, elle est quelque part. Mais généralement pas au même
endroit que le code.
De là, il est entièrement possible de créer un code assembleur de la
fonction copié (la même, mais copiée, comme on copie en C++ avec un
constructeur par recopie), mais de prendre pour variable static aussi
des copies des variables?
Sauf que dans le code compilé, je ne pense pas qu'on
fasse aucune différence entre une variable globale et
une variable statique. Creer une nouvelle instance de
la fonction qui gère cette différence, pas facile.
De toute façon, ça ne serait pas un simple "memcpy"
mais une fonction particulière (genre "fctcpy").
Et ça suppose qu'on aille créer synamiquement du code.
En plus, ce serait assez inefficace: pour s'éviter un passage
de paramètre d'aller recopier tout le code exécutable.
Pour finir, en C++, ben, il y a un paramêtre caché "this"
aux appels de méthodes membres.
D'où ma question sur le _inline qui est a ma
connaissance une copie du code de la fonction.
Mais qui se fait à la compilation, pas à l'exécution.
Parce que je n'ai pas testé, mais je suppose que deux pointeurs de
fonction qui pointent sur la même fonction partagent le static (je ne
me trompe pas, là?)
Oui.
Finalement j'ai pris la solution de passer en argument, mais imaginons
que je mette un compteur dans ma fonction, je suis obligé d'utiliser
cette ruse de passage par argument.
Oui.
Marc Boyer
--
Je ne respecte plus le code de la route à vélo depuis une double fracture
due au fait que j'étais le seul à le respecter.
Ok je suis peut être ignorant, mais une variable static est quelque part en ram? Enfin en tout cas dans la mémoire heap.
Oui, elle est quelque part. Mais généralement pas au même endroit que le code.
De là, il est entièrement possible de créer un code assembleur de la fonction copié (la même, mais copiée, comme on copie en C++ avec un constructeur par recopie), mais de prendre pour variable static aussi des copies des variables?
Sauf que dans le code compilé, je ne pense pas qu'on fasse aucune différence entre une variable globale et une variable statique. Creer une nouvelle instance de la fonction qui gère cette différence, pas facile. De toute façon, ça ne serait pas un simple "memcpy" mais une fonction particulière (genre "fctcpy"). Et ça suppose qu'on aille créer synamiquement du code. En plus, ce serait assez inefficace: pour s'éviter un passage de paramètre d'aller recopier tout le code exécutable. Pour finir, en C++, ben, il y a un paramêtre caché "this" aux appels de méthodes membres.
D'où ma question sur le _inline qui est a ma connaissance une copie du code de la fonction.
Mais qui se fait à la compilation, pas à l'exécution.
Parce que je n'ai pas testé, mais je suppose que deux pointeurs de fonction qui pointent sur la même fonction partagent le static (je ne me trompe pas, là?)
Oui.
Finalement j'ai pris la solution de passer en argument, mais imaginons que je mette un compteur dans ma fonction, je suis obligé d'utiliser cette ruse de passage par argument.
Oui.
Marc Boyer -- Je ne respecte plus le code de la route à vélo depuis une double fracture due au fait que j'étais le seul à le respecter.
Okerampa
Ah oui effectivement petit problème de la génération de code à l'execution je me suis encore fourvoyé. Ben merci pour les réponses :)
Ah oui effectivement petit problème de la génération de code à
l'execution je me suis encore fourvoyé. Ben merci pour les réponses :)
Ah oui effectivement petit problème de la génération de code à l'execution je me suis encore fourvoyé. Ben merci pour les réponses :)
Antoine Leca
En <news:, Marc Boyer va escriure:
Sauf que dans le code compilé, je ne pense pas qu'on fasse aucune différence entre une variable globale et une variable statique.
Dans un .so (objet partagé, bibliothèque dynamique ou DLL si vous préférez), il peut y en avoir une.
Pour une variable globale (externe), le compilateur doit supposer qu'une autre unité va faire joujou aussi avec la variable. Donc il est obligé de projeter l'instance de la variable en mémoire privée du processus, avec accès obligatoirement à travers d'un pointeur relatif à la position du code (GOT), et de plus de signaler au chargeur (ld.so) la logique pour initialiser la dite variable à _chaque_ processus qui se lie à l'objet partagé (le truc qui fait cela s'appelle RELOC_COPY).
Pour une variable static, le compilateur sait que la variable n'est utilisée que dans l'unité en question, donc il est libre de mettre l'objet où il veut dans l'espace virtuel (suivant s'il est modifiable ou pas, initialisé ou pas, à une valeur constante ou à une adresse relogeable), et de l'accéder comme il lui plaît en fonction du choix déduit. Évidemment, dans le dernier des cas (éventuellement modifiable et initialisé à une adresse), il faut en passer par la même démarche que ci-dessus; mais dans les autres cas tu peux faire plus simple et aller plus vite.
Antoine
En <news:slrndatg97.qro.Marc.Boyer@localhost.localdomain>,
Marc Boyer va escriure:
Sauf que dans le code compilé, je ne pense pas qu'on
fasse aucune différence entre une variable globale et
une variable statique.
Dans un .so (objet partagé, bibliothèque dynamique ou DLL si vous préférez),
il peut y en avoir une.
Pour une variable globale (externe), le compilateur doit supposer qu'une
autre unité va faire joujou aussi avec la variable. Donc il est obligé de
projeter l'instance de la variable en mémoire privée du processus, avec
accès obligatoirement à travers d'un pointeur relatif à la position du code
(GOT), et de plus de signaler au chargeur (ld.so) la logique pour
initialiser la dite variable à _chaque_ processus qui se lie à l'objet
partagé (le truc qui fait cela s'appelle RELOC_COPY).
Pour une variable static, le compilateur sait que la variable n'est utilisée
que dans l'unité en question, donc il est libre de mettre l'objet où il veut
dans l'espace virtuel (suivant s'il est modifiable ou pas, initialisé ou
pas, à une valeur constante ou à une adresse relogeable), et de l'accéder
comme il lui plaît en fonction du choix déduit. Évidemment, dans le dernier
des cas (éventuellement modifiable et initialisé à une adresse), il faut en
passer par la même démarche que ci-dessus; mais dans les autres cas tu peux
faire plus simple et aller plus vite.
Sauf que dans le code compilé, je ne pense pas qu'on fasse aucune différence entre une variable globale et une variable statique.
Dans un .so (objet partagé, bibliothèque dynamique ou DLL si vous préférez), il peut y en avoir une.
Pour une variable globale (externe), le compilateur doit supposer qu'une autre unité va faire joujou aussi avec la variable. Donc il est obligé de projeter l'instance de la variable en mémoire privée du processus, avec accès obligatoirement à travers d'un pointeur relatif à la position du code (GOT), et de plus de signaler au chargeur (ld.so) la logique pour initialiser la dite variable à _chaque_ processus qui se lie à l'objet partagé (le truc qui fait cela s'appelle RELOC_COPY).
Pour une variable static, le compilateur sait que la variable n'est utilisée que dans l'unité en question, donc il est libre de mettre l'objet où il veut dans l'espace virtuel (suivant s'il est modifiable ou pas, initialisé ou pas, à une valeur constante ou à une adresse relogeable), et de l'accéder comme il lui plaît en fonction du choix déduit. Évidemment, dans le dernier des cas (éventuellement modifiable et initialisé à une adresse), il faut en passer par la même démarche que ci-dessus; mais dans les autres cas tu peux faire plus simple et aller plus vite.
Antoine
Jean-Claude Arbaut
Le 14/06/2005 12:37, dans d8mbt3$jq6$, « fabrizio » a écrit :
Okerampa wrote:
Ok je suis peut être ignorant, mais une variable static est quelque part en ram? Enfin en tout cas dans la mémoire heap.
Il me semble que le tas (heap) et la zone statique (static) sont deux zones différentes de l'espace mémoire virtuel d'un processus. Peut-être est-ce différent d'un système à un autre.
Déjà il faudrait savoir ce qu'est le tas... Sous DOS et avec Turbo Pascal, je me rappelle à peu près. Mais prenons MacOSX: le programme a un espace d'adressage de 32 bits, et le programme se trouve à l'adresse 0 (4K de segment zéro, suivi des segments TEXT et DATA). En principe, les variables statiques sont dans le DATA/BSS ou quelque chose du même genre (il faudrait que je vérifie). Quant au tas... Il n'existe pas vraiment, tout l'espace peut a priori servir de mémoire utilisateur, sauf qu'une partie est réservée à la pile, une autres aux DLL système, etc... L'espace libre n'est même pas contigu. D'autre part, la mémoire n'est pas accessible par défaut, si on fait un read/write sans malloc préalable, on plante le programme avec une "Segmentation Fault". J'ignore quel est le type de segment alloué par malloc, ça doit ressembler à un mmap anonyme, sauf qu'avec mmap on peut choisir précisément l'emplacement et les droits du bloc alloué. Enfin, il est possible d'allouer 2GiB si on le désire, la RAM n'est pas touchée tant qu'on y accède pas. Pour cette raison il est plus efficace de faire un calloc qu'un malloc suivi de "memset(0)". Voilà, si ça peut aider...
Ce qui n'a rien à voir avec votre discours, je sais.
Aucune importance, c'est un sujet aussi intéressant que l'autre, j'aimerais d'ailleurs savoir ce qu'il en est des autres plateformes.
Le 14/06/2005 12:37, dans d8mbt3$jq6$1@utcnews.utc.fr, « fabrizio »
<watch.the@stars.mw> a écrit :
Okerampa wrote:
Ok je suis peut être ignorant, mais une variable static est quelque
part en ram? Enfin en tout cas dans la mémoire heap.
Il me semble que le tas (heap) et la zone statique (static) sont
deux zones différentes de l'espace mémoire virtuel d'un processus.
Peut-être est-ce différent d'un système à un autre.
Déjà il faudrait savoir ce qu'est le tas... Sous DOS et avec Turbo
Pascal, je me rappelle à peu près. Mais prenons MacOSX: le programme
a un espace d'adressage de 32 bits, et le programme se trouve
à l'adresse 0 (4K de segment zéro, suivi des segments TEXT et DATA).
En principe, les variables statiques sont dans le DATA/BSS ou quelque
chose du même genre (il faudrait que je vérifie). Quant au tas...
Il n'existe pas vraiment, tout l'espace peut a priori servir de
mémoire utilisateur, sauf qu'une partie est réservée à la pile,
une autres aux DLL système, etc... L'espace libre n'est même pas
contigu. D'autre part, la mémoire n'est pas accessible par défaut,
si on fait un read/write sans malloc préalable, on plante le
programme avec une "Segmentation Fault". J'ignore quel est le type
de segment alloué par malloc, ça doit ressembler à un mmap anonyme,
sauf qu'avec mmap on peut choisir précisément l'emplacement et les
droits du bloc alloué. Enfin, il est possible d'allouer 2GiB si
on le désire, la RAM n'est pas touchée tant qu'on y accède pas.
Pour cette raison il est plus efficace de faire un calloc
qu'un malloc suivi de "memset(0)". Voilà, si ça peut aider...
Ce qui n'a rien à voir avec votre discours, je sais.
Aucune importance, c'est un sujet aussi intéressant que l'autre,
j'aimerais d'ailleurs savoir ce qu'il en est des autres plateformes.
Le 14/06/2005 12:37, dans d8mbt3$jq6$, « fabrizio » a écrit :
Okerampa wrote:
Ok je suis peut être ignorant, mais une variable static est quelque part en ram? Enfin en tout cas dans la mémoire heap.
Il me semble que le tas (heap) et la zone statique (static) sont deux zones différentes de l'espace mémoire virtuel d'un processus. Peut-être est-ce différent d'un système à un autre.
Déjà il faudrait savoir ce qu'est le tas... Sous DOS et avec Turbo Pascal, je me rappelle à peu près. Mais prenons MacOSX: le programme a un espace d'adressage de 32 bits, et le programme se trouve à l'adresse 0 (4K de segment zéro, suivi des segments TEXT et DATA). En principe, les variables statiques sont dans le DATA/BSS ou quelque chose du même genre (il faudrait que je vérifie). Quant au tas... Il n'existe pas vraiment, tout l'espace peut a priori servir de mémoire utilisateur, sauf qu'une partie est réservée à la pile, une autres aux DLL système, etc... L'espace libre n'est même pas contigu. D'autre part, la mémoire n'est pas accessible par défaut, si on fait un read/write sans malloc préalable, on plante le programme avec une "Segmentation Fault". J'ignore quel est le type de segment alloué par malloc, ça doit ressembler à un mmap anonyme, sauf qu'avec mmap on peut choisir précisément l'emplacement et les droits du bloc alloué. Enfin, il est possible d'allouer 2GiB si on le désire, la RAM n'est pas touchée tant qu'on y accède pas. Pour cette raison il est plus efficace de faire un calloc qu'un malloc suivi de "memset(0)". Voilà, si ça peut aider...
Ce qui n'a rien à voir avec votre discours, je sais.
Aucune importance, c'est un sujet aussi intéressant que l'autre, j'aimerais d'ailleurs savoir ce qu'il en est des autres plateformes.
