Je suis à la recherche de code source d'un compilateur écrit en lex
et bison.
je voudrai avoir de la documentation sur la partie d'adressage
mémoire, sur la maniere d'implémenter l'allocation de mémoire (stack,
heap) et les structures de blocs dépendament de la machine
| > Tout ceci est totalement spécifique à l'environnement C sur Unix | > (donc pas vrai en général, ni pour d'autres langages, ni pour | > d'autres systèmes). | | Ne nous focalisons pas sur la lic. Je présentais cette technique | pour dire que l'allocation dynamique n'était pas gérée par | le *compilateur* mais par des éléments éxtérieurs, sur | des plateformes assez classiques.
Je ne suis pas d'accord avec ta formulation.
Dans un langage au moins aussi répandu que le C -- C++ pour ne pas le nommer -- la gestion de l'allocation dynamique est une affaire qui concerne en premier lieu le compilateur, dont ce dernier délègue un bout à des codes non-directement câblés.
C'est une erreur, je l'admets assez répandue dans la communauté C, de croire que l'allocation dynamique ne concerne pas le compilateur, que l'on en droit de pirater la bibliothèque C.
-- Gaby
Marc Boyer <Marc.Boyer@enseeiht.yahoo.fr> writes:
| > Tout ceci est totalement spécifique à l'environnement C sur Unix
| > (donc pas vrai en général, ni pour d'autres langages, ni pour
| > d'autres systèmes).
|
| Ne nous focalisons pas sur la lic. Je présentais cette technique
| pour dire que l'allocation dynamique n'était pas gérée par
| le *compilateur* mais par des éléments éxtérieurs, sur
| des plateformes assez classiques.
Je ne suis pas d'accord avec ta formulation.
Dans un langage au moins aussi répandu que le C -- C++ pour ne pas le
nommer -- la gestion de l'allocation dynamique est une affaire qui
concerne en premier lieu le compilateur, dont ce dernier délègue un
bout à des codes non-directement câblés.
C'est une erreur, je l'admets assez répandue dans la communauté C, de
croire que l'allocation dynamique ne concerne pas le compilateur, que
l'on en droit de pirater la bibliothèque C.
| > Tout ceci est totalement spécifique à l'environnement C sur Unix | > (donc pas vrai en général, ni pour d'autres langages, ni pour | > d'autres systèmes). | | Ne nous focalisons pas sur la lic. Je présentais cette technique | pour dire que l'allocation dynamique n'était pas gérée par | le *compilateur* mais par des éléments éxtérieurs, sur | des plateformes assez classiques.
Je ne suis pas d'accord avec ta formulation.
Dans un langage au moins aussi répandu que le C -- C++ pour ne pas le nommer -- la gestion de l'allocation dynamique est une affaire qui concerne en premier lieu le compilateur, dont ce dernier délègue un bout à des codes non-directement câblés.
C'est une erreur, je l'admets assez répandue dans la communauté C, de croire que l'allocation dynamique ne concerne pas le compilateur, que l'on en droit de pirater la bibliothèque C.
-- Gaby
Jean-Marc Bourguet
Marc Boyer writes:
Sur Linux, malloc/free sont dans libc, et pas dans GCC.
Sous Linux (et sous Unix en general), il y a de la confusion(*) entre la bibliotheque standard du C et les bibliotheques d'interfacage de l'OS.
(Je ne sais plus qui a dit qu'entre confusion et unification il n'y avait qu'un degre de desirabilite).
A+
-- Jean-Marc FAQ de fclc: http://www.isty-info.uvsq.fr/~rumeau/fclc Site de usenet-fr: http://www.usenet-fr.news.eu.org
Marc Boyer <Marc.Boyer@enseeiht.yahoo.fr> writes:
Sur Linux, malloc/free sont dans libc, et pas dans GCC.
Sous Linux (et sous Unix en general), il y a de la confusion(*) entre
la bibliotheque standard du C et les bibliotheques d'interfacage de
l'OS.
(Je ne sais plus qui a dit qu'entre confusion et unification il n'y
avait qu'un degre de desirabilite).
A+
--
Jean-Marc
FAQ de fclc: http://www.isty-info.uvsq.fr/~rumeau/fclc
Site de usenet-fr: http://www.usenet-fr.news.eu.org
Sur Linux, malloc/free sont dans libc, et pas dans GCC.
Sous Linux (et sous Unix en general), il y a de la confusion(*) entre la bibliotheque standard du C et les bibliotheques d'interfacage de l'OS.
(Je ne sais plus qui a dit qu'entre confusion et unification il n'y avait qu'un degre de desirabilite).
A+
-- Jean-Marc FAQ de fclc: http://www.isty-info.uvsq.fr/~rumeau/fclc Site de usenet-fr: http://www.usenet-fr.news.eu.org
Vincent Lefevre
Dans l'article <bg30eo$8le$, Marc Boyer écrit:
Antoine Leca wrote:
Dans "libc", il y a... C. C'est donc plus ou moins spécifique à C, non ?
Oui et non. Oui, si on considère que le C est un langage "comme les autres". Non dans le sens ou le C est quasiment "universel", et que, hormis cas très spécifique, si tu as à écrire un compilo (autre qu'assembleur) sur une platerforme donnée, il y a de *très* fortes chances qu'il existe déjà un compilateur C.
C'est faux pour les Psion (sous EPOC), malheureusement (et c'est une des raisons pour lesquelles je n'utilise quasiment plus le mien).
Tout ceci est totalement spécifique à l'environnement C sur Unix (donc pas vrai en général, ni pour d'autres langages, ni pour d'autres systèmes).
Ne nous focalisons pas sur la lic. Je présentais cette technique pour dire que l'allocation dynamique n'était pas gérée par le *compilateur* mais par des éléments éxtérieurs, sur des plateformes assez classiques.
Je ne sais pas ce qui se passe en pratique pour l'ensemble des compilateurs. Mais il n'y a pas de raison pour passer l'allocation dynamique à des éléments extérieurs. D'ailleurs, l'allocation de variables automatiques (c'est bien de l'allocation dynamique, non?) est généralement faite uniquement par de la génération de code.
Reprenons le thread à son origine. Le PO demandait des sources pour savoir comment le compilateur gérait l'allocation mémoire, dynamique (tas+pile) et statique. et je lui disais que, hormis cas spécifiques, la gestion du tas dynamique n'était pas de son ressort, mais du contexte d'exécution (OS+lib qui va bien, machine virtuelle...)
Justement, il demandait les sources d'un compilateur (mais pas forcément d'un compilateur C uniquement), et on pourrait concevoir des langages où seul le compilateur pourrait se débrouiller proprement pour l'allocation dynamique.
-- Vincent Lefèvre - Web: <http://www.vinc17.org/> - 100% validated (X)HTML - Acorn Risc PC, Yellow Pig 17, Championnat International des Jeux Mathématiques et Logiques, TETRHEX, etc. Work: CR INRIA - computer arithmetic / SPACES project at LORIA
Dans l'article <bg30eo$8le$2@news.cict.fr>,
Marc Boyer <Marc.Boyer@enseeiht.yahoo.fr> écrit:
Antoine Leca wrote:
Dans "libc", il y a... C. C'est donc plus ou moins spécifique à C, non ?
Oui et non. Oui, si on considère que le C est un langage
"comme les autres". Non dans le sens ou le C est quasiment
"universel", et que, hormis cas très spécifique, si tu as à
écrire un compilo (autre qu'assembleur) sur une platerforme
donnée, il y a de *très* fortes chances qu'il existe déjà
un compilateur C.
C'est faux pour les Psion (sous EPOC), malheureusement (et c'est
une des raisons pour lesquelles je n'utilise quasiment plus le
mien).
Tout ceci est totalement spécifique à l'environnement C sur Unix
(donc pas vrai en général, ni pour d'autres langages, ni pour
d'autres systèmes).
Ne nous focalisons pas sur la lic. Je présentais cette technique
pour dire que l'allocation dynamique n'était pas gérée par
le *compilateur* mais par des éléments éxtérieurs, sur
des plateformes assez classiques.
Je ne sais pas ce qui se passe en pratique pour l'ensemble des
compilateurs. Mais il n'y a pas de raison pour passer l'allocation
dynamique à des éléments extérieurs. D'ailleurs, l'allocation de
variables automatiques (c'est bien de l'allocation dynamique, non?)
est généralement faite uniquement par de la génération de code.
Reprenons le thread à son origine.
Le PO demandait des sources pour savoir comment le compilateur
gérait l'allocation mémoire, dynamique (tas+pile) et statique.
et je lui disais que, hormis cas spécifiques, la gestion
du tas dynamique n'était pas de son ressort, mais du contexte
d'exécution (OS+lib qui va bien, machine virtuelle...)
Justement, il demandait les sources d'un compilateur (mais pas
forcément d'un compilateur C uniquement), et on pourrait concevoir
des langages où seul le compilateur pourrait se débrouiller
proprement pour l'allocation dynamique.
--
Vincent Lefèvre <vincent@vinc17.org> - Web: <http://www.vinc17.org/> - 100%
validated (X)HTML - Acorn Risc PC, Yellow Pig 17, Championnat International
des Jeux Mathématiques et Logiques, TETRHEX, etc.
Work: CR INRIA - computer arithmetic / SPACES project at LORIA
Dans "libc", il y a... C. C'est donc plus ou moins spécifique à C, non ?
Oui et non. Oui, si on considère que le C est un langage "comme les autres". Non dans le sens ou le C est quasiment "universel", et que, hormis cas très spécifique, si tu as à écrire un compilo (autre qu'assembleur) sur une platerforme donnée, il y a de *très* fortes chances qu'il existe déjà un compilateur C.
C'est faux pour les Psion (sous EPOC), malheureusement (et c'est une des raisons pour lesquelles je n'utilise quasiment plus le mien).
Tout ceci est totalement spécifique à l'environnement C sur Unix (donc pas vrai en général, ni pour d'autres langages, ni pour d'autres systèmes).
Ne nous focalisons pas sur la lic. Je présentais cette technique pour dire que l'allocation dynamique n'était pas gérée par le *compilateur* mais par des éléments éxtérieurs, sur des plateformes assez classiques.
Je ne sais pas ce qui se passe en pratique pour l'ensemble des compilateurs. Mais il n'y a pas de raison pour passer l'allocation dynamique à des éléments extérieurs. D'ailleurs, l'allocation de variables automatiques (c'est bien de l'allocation dynamique, non?) est généralement faite uniquement par de la génération de code.
Reprenons le thread à son origine. Le PO demandait des sources pour savoir comment le compilateur gérait l'allocation mémoire, dynamique (tas+pile) et statique. et je lui disais que, hormis cas spécifiques, la gestion du tas dynamique n'était pas de son ressort, mais du contexte d'exécution (OS+lib qui va bien, machine virtuelle...)
Justement, il demandait les sources d'un compilateur (mais pas forcément d'un compilateur C uniquement), et on pourrait concevoir des langages où seul le compilateur pourrait se débrouiller proprement pour l'allocation dynamique.
-- Vincent Lefèvre - Web: <http://www.vinc17.org/> - 100% validated (X)HTML - Acorn Risc PC, Yellow Pig 17, Championnat International des Jeux Mathématiques et Logiques, TETRHEX, etc. Work: CR INRIA - computer arithmetic / SPACES project at LORIA
Marc Boyer
In article , Jean-Marc Bourguet wrote:
Marc Boyer writes:
Sur Linux, malloc/free sont dans libc, et pas dans GCC.
Sous Linux (et sous Unix en general), il y a de la confusion(*) entre la bibliotheque standard du C et les bibliotheques d'interfacage de l'OS.
Suite à de longues discussions entre OS, noyau, modules sur fcol (de mémoire), on avait finit par converger vers le fait que la libc faisait partie de ce que l'on nomme communément OS (d'ou l'appellation "GNU/Linux" pour l'OS et non juste "Linux"). Mais bon, on peut reprendre la discussion encore une fois si tu veux.
Marc PS: En cas de suite, je te laisse choisir un fu2 vers fco.unix, fco.linux ou autre -- Lying for having sex or lying for making war? Trust US presidents :-(
In article <pxbbrvelo6v.fsf@news.bourguet.org>, Jean-Marc Bourguet wrote:
Marc Boyer <Marc.Boyer@enseeiht.yahoo.fr> writes:
Sur Linux, malloc/free sont dans libc, et pas dans GCC.
Sous Linux (et sous Unix en general), il y a de la confusion(*) entre
la bibliotheque standard du C et les bibliotheques d'interfacage de
l'OS.
Suite à de longues discussions entre OS, noyau, modules
sur fcol (de mémoire), on avait finit par converger vers le
fait que la libc faisait partie de ce que l'on nomme
communément OS (d'ou l'appellation "GNU/Linux" pour l'OS
et non juste "Linux").
Mais bon, on peut reprendre la discussion encore
une fois si tu veux.
Marc
PS: En cas de suite, je te laisse choisir un fu2
vers fco.unix, fco.linux ou autre
--
Lying for having sex or lying for making war? Trust US presidents :-(
Sur Linux, malloc/free sont dans libc, et pas dans GCC.
Sous Linux (et sous Unix en general), il y a de la confusion(*) entre la bibliotheque standard du C et les bibliotheques d'interfacage de l'OS.
Suite à de longues discussions entre OS, noyau, modules sur fcol (de mémoire), on avait finit par converger vers le fait que la libc faisait partie de ce que l'on nomme communément OS (d'ou l'appellation "GNU/Linux" pour l'OS et non juste "Linux"). Mais bon, on peut reprendre la discussion encore une fois si tu veux.
Marc PS: En cas de suite, je te laisse choisir un fu2 vers fco.unix, fco.linux ou autre -- Lying for having sex or lying for making war? Trust US presidents :-(
Gabriel Dos Reis
Marc Boyer writes:
| Gabriel Dos Reis wrote: | > Marc Boyer writes: | > | >| Ne nous focalisons pas sur la lic. Je présentais cette technique | >| pour dire que l'allocation dynamique n'était pas gérée par | >| le *compilateur* mais par des éléments éxtérieurs, sur | >| des plateformes assez classiques. | > | > Je ne suis pas d'accord avec ta formulation. | > | > Dans un langage au moins aussi répandu que le C -- C++ pour ne pas le | > nommer -- la gestion de l'allocation dynamique est une affaire qui | > concerne en premier lieu le compilateur, dont ce dernier délègue un | > bout à des codes non-directement câblés. | > | > C'est une erreur, je l'admets assez répandue dans la communauté C, de | > croire que l'allocation dynamique ne concerne pas le compilateur, que | > l'on en droit de pirater la bibliothèque C. | | Heuh... Je ne remets absolument pas en doute ta compétence, | mais j'aimerais alors avoir des explications. | Sur Linux, malloc/free sont dans libc, et pas dans GCC.
Oui, mais ce n'est pas un exemple à multiplier. Et beaucoup de cela provient de la confusion. Il fût un moment, pas si lointain que ça finalement, pour pouvoir utiliser g++, il faillait aller chercher séparément libg++. Heureusement, maintenant on un couplage plus fort entre GCC/g++ et libstdc++.
Il faudra du temps pour que la situation s'améliore pour GCC/gcc et la libc.
| J'ai donc tendance à considérer que c'est dans l'OS plus que | dans le compilateur. Ou plante mon raisonnement ?
La confusion vient de ce que certains donnent le même nom à deux choses qui sont conceptuellement différentes.
L'OS fournit des primitives d'allocation dynamique (genre sbrk). Et l'implémentation peut utiliser ces primitives pour offrir malloc. Il arrive simplement que certains OS offrent des routines d'allocations qu'ils appellent malloc et que certains implémentations confusantes (et il en existe beaucoup) la repassent aux programmes.
| Et en ce qui concerne C++, le "Modern C++ design" propose | une implémentation d'un allocateur pour petis objets en arguant | que new/delete reposent sur malloc/free.
Dis comme cela, c'est clairement faux. Peux-tu me donner la référence (i.e. no de page)?
-- Gaby
Marc Boyer <Marc.Boyer@enseeiht.yahoo.fr> writes:
| Gabriel Dos Reis wrote:
| > Marc Boyer <Marc.Boyer@enseeiht.yahoo.fr> writes:
| >
| >| Ne nous focalisons pas sur la lic. Je présentais cette technique
| >| pour dire que l'allocation dynamique n'était pas gérée par
| >| le *compilateur* mais par des éléments éxtérieurs, sur
| >| des plateformes assez classiques.
| >
| > Je ne suis pas d'accord avec ta formulation.
| >
| > Dans un langage au moins aussi répandu que le C -- C++ pour ne pas le
| > nommer -- la gestion de l'allocation dynamique est une affaire qui
| > concerne en premier lieu le compilateur, dont ce dernier délègue un
| > bout à des codes non-directement câblés.
| >
| > C'est une erreur, je l'admets assez répandue dans la communauté C, de
| > croire que l'allocation dynamique ne concerne pas le compilateur, que
| > l'on en droit de pirater la bibliothèque C.
|
| Heuh... Je ne remets absolument pas en doute ta compétence,
| mais j'aimerais alors avoir des explications.
| Sur Linux, malloc/free sont dans libc, et pas dans GCC.
Oui, mais ce n'est pas un exemple à multiplier. Et beaucoup de cela
provient de la confusion.
Il fût un moment, pas si lointain que ça finalement, pour pouvoir
utiliser g++, il faillait aller chercher séparément libg++.
Heureusement, maintenant on un couplage plus fort entre GCC/g++ et
libstdc++.
Il faudra du temps pour que la situation s'améliore pour GCC/gcc et la
libc.
| J'ai donc tendance à considérer que c'est dans l'OS plus que
| dans le compilateur. Ou plante mon raisonnement ?
La confusion vient de ce que certains donnent le même nom à deux
choses qui sont conceptuellement différentes.
L'OS fournit des primitives d'allocation dynamique (genre sbrk).
Et l'implémentation peut utiliser ces primitives pour offrir malloc.
Il arrive simplement que certains OS offrent des routines
d'allocations qu'ils appellent malloc et que certains implémentations
confusantes (et il en existe beaucoup) la repassent aux programmes.
| Et en ce qui concerne C++, le "Modern C++ design" propose
| une implémentation d'un allocateur pour petis objets en arguant
| que new/delete reposent sur malloc/free.
Dis comme cela, c'est clairement faux. Peux-tu me donner la référence
(i.e. no de page)?
| Gabriel Dos Reis wrote: | > Marc Boyer writes: | > | >| Ne nous focalisons pas sur la lic. Je présentais cette technique | >| pour dire que l'allocation dynamique n'était pas gérée par | >| le *compilateur* mais par des éléments éxtérieurs, sur | >| des plateformes assez classiques. | > | > Je ne suis pas d'accord avec ta formulation. | > | > Dans un langage au moins aussi répandu que le C -- C++ pour ne pas le | > nommer -- la gestion de l'allocation dynamique est une affaire qui | > concerne en premier lieu le compilateur, dont ce dernier délègue un | > bout à des codes non-directement câblés. | > | > C'est une erreur, je l'admets assez répandue dans la communauté C, de | > croire que l'allocation dynamique ne concerne pas le compilateur, que | > l'on en droit de pirater la bibliothèque C. | | Heuh... Je ne remets absolument pas en doute ta compétence, | mais j'aimerais alors avoir des explications. | Sur Linux, malloc/free sont dans libc, et pas dans GCC.
Oui, mais ce n'est pas un exemple à multiplier. Et beaucoup de cela provient de la confusion. Il fût un moment, pas si lointain que ça finalement, pour pouvoir utiliser g++, il faillait aller chercher séparément libg++. Heureusement, maintenant on un couplage plus fort entre GCC/g++ et libstdc++.
Il faudra du temps pour que la situation s'améliore pour GCC/gcc et la libc.
| J'ai donc tendance à considérer que c'est dans l'OS plus que | dans le compilateur. Ou plante mon raisonnement ?
La confusion vient de ce que certains donnent le même nom à deux choses qui sont conceptuellement différentes.
L'OS fournit des primitives d'allocation dynamique (genre sbrk). Et l'implémentation peut utiliser ces primitives pour offrir malloc. Il arrive simplement que certains OS offrent des routines d'allocations qu'ils appellent malloc et que certains implémentations confusantes (et il en existe beaucoup) la repassent aux programmes.
| Et en ce qui concerne C++, le "Modern C++ design" propose | une implémentation d'un allocateur pour petis objets en arguant | que new/delete reposent sur malloc/free.
Dis comme cela, c'est clairement faux. Peux-tu me donner la référence (i.e. no de page)?
-- Gaby
Gabriel Dos Reis
Vincent Lefevre <vincent+ writes:
| Dans l'article <bfrhjc$12d$, | Marc Boyer écrit: | | > Ce que je dis, c'est que malloc/free sous Solaris et Linux | > sont gérés par la libc et l'OS. Et je soupsonne que de nombreux | > langages procéduraux qui ont un fonctionnement assez similaire | > (Pascal, Ada, Eiffel, C++) utilisent ces malloc/free de plus | > ou moins prêt. Et je pense que pas mal d'OS ont le même | > découpage. | | Pas forcément. Même certains programmes C peuvent utiliser d'autres | choses (e.g. alloca, existant sous certains OS),
Ce que fait alloca est plus proche de la mémoire automatique que de la mémoire dynamique.
-- Gaby
Vincent Lefevre <vincent+news@vinc17.org> writes:
| Dans l'article <bfrhjc$12d$1@news.cict.fr>,
| Marc Boyer <Marc.Boyer@enseeiht.yahoo.fr> écrit:
|
| > Ce que je dis, c'est que malloc/free sous Solaris et Linux
| > sont gérés par la libc et l'OS. Et je soupsonne que de nombreux
| > langages procéduraux qui ont un fonctionnement assez similaire
| > (Pascal, Ada, Eiffel, C++) utilisent ces malloc/free de plus
| > ou moins prêt. Et je pense que pas mal d'OS ont le même
| > découpage.
|
| Pas forcément. Même certains programmes C peuvent utiliser d'autres
| choses (e.g. alloca, existant sous certains OS),
Ce que fait alloca est plus proche de la mémoire automatique que de la
mémoire dynamique.
| Dans l'article <bfrhjc$12d$, | Marc Boyer écrit: | | > Ce que je dis, c'est que malloc/free sous Solaris et Linux | > sont gérés par la libc et l'OS. Et je soupsonne que de nombreux | > langages procéduraux qui ont un fonctionnement assez similaire | > (Pascal, Ada, Eiffel, C++) utilisent ces malloc/free de plus | > ou moins prêt. Et je pense que pas mal d'OS ont le même | > découpage. | | Pas forcément. Même certains programmes C peuvent utiliser d'autres | choses (e.g. alloca, existant sous certains OS),
Ce que fait alloca est plus proche de la mémoire automatique que de la mémoire dynamique.
-- Gaby
Gabriel Dos Reis
Vincent Lefevre <vincent+ writes:
| >> Tout ceci est totalement spécifique à l'environnement C sur Unix | >> (donc pas vrai en général, ni pour d'autres langages, ni pour | >> d'autres systèmes). | > | > Ne nous focalisons pas sur la lic. Je présentais cette technique | > pour dire que l'allocation dynamique n'était pas gérée par | > le *compilateur* mais par des éléments éxtérieurs, sur | > des plateformes assez classiques. | | Je ne sais pas ce qui se passe en pratique pour l'ensemble des | compilateurs. Mais il n'y a pas de raison pour passer l'allocation | dynamique à des éléments extérieurs. D'ailleurs, l'allocation de | variables automatiques (c'est bien de l'allocation dynamique, non?)
non.
| est généralement faite uniquement par de la génération de code.
-- Gaby
Vincent Lefevre <vincent+news@vinc17.org> writes:
| >> Tout ceci est totalement spécifique à l'environnement C sur Unix
| >> (donc pas vrai en général, ni pour d'autres langages, ni pour
| >> d'autres systèmes).
| >
| > Ne nous focalisons pas sur la lic. Je présentais cette technique
| > pour dire que l'allocation dynamique n'était pas gérée par
| > le *compilateur* mais par des éléments éxtérieurs, sur
| > des plateformes assez classiques.
|
| Je ne sais pas ce qui se passe en pratique pour l'ensemble des
| compilateurs. Mais il n'y a pas de raison pour passer l'allocation
| dynamique à des éléments extérieurs. D'ailleurs, l'allocation de
| variables automatiques (c'est bien de l'allocation dynamique, non?)
non.
| est généralement faite uniquement par de la génération de code.
| >> Tout ceci est totalement spécifique à l'environnement C sur Unix | >> (donc pas vrai en général, ni pour d'autres langages, ni pour | >> d'autres systèmes). | > | > Ne nous focalisons pas sur la lic. Je présentais cette technique | > pour dire que l'allocation dynamique n'était pas gérée par | > le *compilateur* mais par des éléments éxtérieurs, sur | > des plateformes assez classiques. | | Je ne sais pas ce qui se passe en pratique pour l'ensemble des | compilateurs. Mais il n'y a pas de raison pour passer l'allocation | dynamique à des éléments extérieurs. D'ailleurs, l'allocation de | variables automatiques (c'est bien de l'allocation dynamique, non?)
non.
| est généralement faite uniquement par de la génération de code.
-- Gaby
Vincent Lefevre
Dans l'article , Gabriel Dos Reis écrit:
Ce que fait alloca est plus proche de la mémoire automatique que de la mémoire dynamique.
Si tu veux différencier mémoire automatique et mémoire dynamique comme tu sembles le faire, pourquoi pas. Tu as une définition *officielle* de "mémoire automatique" et "mémoire dynamique"?
-- Vincent Lefèvre - Web: <http://www.vinc17.org/> - 100% validated (X)HTML - Acorn Risc PC, Yellow Pig 17, Championnat International des Jeux Mathématiques et Logiques, TETRHEX, etc. Work: CR INRIA - computer arithmetic / SPACES project at LORIA
Dans l'article <m34r167lhd.fsf@uniton.integrable-solutions.net>,
Gabriel Dos Reis <gdr@integrable-solutions.net> écrit:
Ce que fait alloca est plus proche de la mémoire automatique que de la
mémoire dynamique.
Si tu veux différencier mémoire automatique et mémoire dynamique comme
tu sembles le faire, pourquoi pas. Tu as une définition *officielle*
de "mémoire automatique" et "mémoire dynamique"?
--
Vincent Lefèvre <vincent@vinc17.org> - Web: <http://www.vinc17.org/> - 100%
validated (X)HTML - Acorn Risc PC, Yellow Pig 17, Championnat International
des Jeux Mathématiques et Logiques, TETRHEX, etc.
Work: CR INRIA - computer arithmetic / SPACES project at LORIA
Ce que fait alloca est plus proche de la mémoire automatique que de la mémoire dynamique.
Si tu veux différencier mémoire automatique et mémoire dynamique comme tu sembles le faire, pourquoi pas. Tu as une définition *officielle* de "mémoire automatique" et "mémoire dynamique"?
-- Vincent Lefèvre - Web: <http://www.vinc17.org/> - 100% validated (X)HTML - Acorn Risc PC, Yellow Pig 17, Championnat International des Jeux Mathématiques et Logiques, TETRHEX, etc. Work: CR INRIA - computer arithmetic / SPACES project at LORIA
Gabriel Dos Reis
Vincent Lefevre <vincent+ writes:
| Dans l'article , | Gabriel Dos Reis écrit: | | > Ce que fait alloca est plus proche de la mémoire automatique que de la | > mémoire dynamique. | | Si tu veux différencier mémoire automatique et mémoire dynamique comme | tu sembles le faire, pourquoi pas. Tu as une définition *officielle* | de "mémoire automatique" et "mémoire dynamique"?
Puisque alloca n'est pas standard, tu ne veux pas une définition officielle qui s'applique à alloca, n'est-il pas ?
Autrement tu peux jeter un coup d'oeil à
6.2.4 Storage durations of objects
-- Gaby
Vincent Lefevre <vincent+news@vinc17.org> writes:
| Dans l'article <m34r167lhd.fsf@uniton.integrable-solutions.net>,
| Gabriel Dos Reis <gdr@integrable-solutions.net> écrit:
|
| > Ce que fait alloca est plus proche de la mémoire automatique que de la
| > mémoire dynamique.
|
| Si tu veux différencier mémoire automatique et mémoire dynamique comme
| tu sembles le faire, pourquoi pas. Tu as une définition *officielle*
| de "mémoire automatique" et "mémoire dynamique"?
Puisque alloca n'est pas standard, tu ne veux pas une définition
officielle qui s'applique à alloca, n'est-il pas ?
| Dans l'article , | Gabriel Dos Reis écrit: | | > Ce que fait alloca est plus proche de la mémoire automatique que de la | > mémoire dynamique. | | Si tu veux différencier mémoire automatique et mémoire dynamique comme | tu sembles le faire, pourquoi pas. Tu as une définition *officielle* | de "mémoire automatique" et "mémoire dynamique"?
Puisque alloca n'est pas standard, tu ne veux pas une définition officielle qui s'applique à alloca, n'est-il pas ?
Autrement tu peux jeter un coup d'oeil à
6.2.4 Storage durations of objects
-- Gaby
Gabriel Dos Reis
Marc Boyer writes:
| > Je ne sais pas ce qui se passe en pratique pour l'ensemble des | > compilateurs. Mais il n'y a pas de raison pour passer l'allocation | > dynamique à des éléments extérieurs. | | Il n'y a pas d'obligation non. | Mais si une platerforme (OS) l'offre, il faut une bonne | raison pour ne pas l'utiliser, non ?
Non. Il suffit simplement d'une raison.
-- Gaby
Marc Boyer <Marc.Boyer@enseeiht.yahoo.fr> writes:
| > Je ne sais pas ce qui se passe en pratique pour l'ensemble des
| > compilateurs. Mais il n'y a pas de raison pour passer l'allocation
| > dynamique à des éléments extérieurs.
|
| Il n'y a pas d'obligation non.
| Mais si une platerforme (OS) l'offre, il faut une bonne
| raison pour ne pas l'utiliser, non ?
| > Je ne sais pas ce qui se passe en pratique pour l'ensemble des | > compilateurs. Mais il n'y a pas de raison pour passer l'allocation | > dynamique à des éléments extérieurs. | | Il n'y a pas d'obligation non. | Mais si une platerforme (OS) l'offre, il faut une bonne | raison pour ne pas l'utiliser, non ?
