Bonsoir,
Dans le droit fil de réflexions sur la récursivité, j'ai un souci de
vocabulaire.
Comment nommer de façon simple l'état d'une fonction qui a été appelée et
qui n'est pas encore retournée ?
C'est par exemple l'état de main() pendant toute la durée du programme.
Active, trop ambiguë, pour moi, cela signifie que le code est dedans.
Vivante ? J'aime bien, mais je n'ose pas.
Corollaire : à quoi appliquer ce terme ? Quand une fonction n'a pas retourné
et que pour une raison ou une autre elle est appelée à nouveau, je pense en
termes d'instanciation. Le parallélisme est effectivement clair, puiqu'il
s'agit de créer un nouveau jeu de données. Comment appelleriez-vous cette
instance de fonction ? Instance de fonction ? thread (ou fil) ne convient
pas, puisque le terme évoque l'idée de déroulement (macroscopiquement)
simultanée, alors que deux "instances" de n'importe quelle fonction ne sont
que "vivantes" en même temps.
Je cible plutôt tout public, en tous cas pas l'universitairre.
Merci d'avance de vos suggestion éclairées.
Bon, apéro ....
Bonsoir, Dans le droit fil de réflexions sur la récursivité, j'ai un souci de vocabulaire. Comment nommer de façon simple l'état d'une fonction qui a été appelée et qui n'est pas encore retournée ?
En cours d'exécution ? En cours ?
Active, trop ambiguë, D'accord.
pour moi, cela signifie que le code est dedans. ??
Vivante ? J'aime bien, mais je n'ose pas. Je n'aime pas trop car la notion de code mort existe et est sans rapport
avec le sujet en question.
Corollaire : à quoi appliquer ce terme ? Quand une fonction n'a pas retourné et que pour une raison ou une autre elle est appelée à nouveau, je pense en termes d'instanciation. Le parallélisme est effectivement clair, puiqu'il s'agit de créer un nouveau jeu de données. Comment appelleriez-vous cette instance de fonction ? Instance de fonction ? thread
J'aurais dit incarnation. Instance me ferait plutôt penser à des fonctions existant physiquement plusieurs fois dans le programme (par exemple des fonction inlinées, des fcts définies dans différentes bibliothèques dynamiques...).
Je cible plutôt tout public, en tous cas pas l'universitairre.
Ca tombe bien, je n'ai pas la formation qui me permettrait de fournir une réponse un tant soit peu universitaire. C'est rare que ce soit un avantage, j'en profite...
-- Loïc
Pierre Maurette wrote:
Bonsoir,
Dans le droit fil de réflexions sur la récursivité, j'ai un souci de
vocabulaire.
Comment nommer de façon simple l'état d'une fonction qui a été appelée et
qui n'est pas encore retournée ?
En cours d'exécution ?
En cours ?
Active, trop ambiguë,
D'accord.
pour moi, cela signifie que le code est dedans.
??
Vivante ? J'aime bien, mais je n'ose pas.
Je n'aime pas trop car la notion de code mort existe et est sans rapport
avec le sujet en question.
Corollaire : à quoi appliquer ce terme ? Quand une fonction n'a pas retourné
et que pour une raison ou une autre elle est appelée à nouveau, je pense en
termes d'instanciation. Le parallélisme est effectivement clair, puiqu'il
s'agit de créer un nouveau jeu de données. Comment appelleriez-vous cette
instance de fonction ? Instance de fonction ? thread
J'aurais dit incarnation. Instance me ferait plutôt penser à des
fonctions existant physiquement plusieurs fois dans le programme (par
exemple des fonction inlinées, des fcts définies dans différentes
bibliothèques dynamiques...).
Je cible plutôt tout public, en tous cas pas l'universitairre.
Ca tombe bien, je n'ai pas la formation qui me permettrait de fournir
une réponse un tant soit peu universitaire. C'est rare que ce soit un
avantage, j'en profite...
Bonsoir, Dans le droit fil de réflexions sur la récursivité, j'ai un souci de vocabulaire. Comment nommer de façon simple l'état d'une fonction qui a été appelée et qui n'est pas encore retournée ?
En cours d'exécution ? En cours ?
Active, trop ambiguë, D'accord.
pour moi, cela signifie que le code est dedans. ??
Vivante ? J'aime bien, mais je n'ose pas. Je n'aime pas trop car la notion de code mort existe et est sans rapport
avec le sujet en question.
Corollaire : à quoi appliquer ce terme ? Quand une fonction n'a pas retourné et que pour une raison ou une autre elle est appelée à nouveau, je pense en termes d'instanciation. Le parallélisme est effectivement clair, puiqu'il s'agit de créer un nouveau jeu de données. Comment appelleriez-vous cette instance de fonction ? Instance de fonction ? thread
J'aurais dit incarnation. Instance me ferait plutôt penser à des fonctions existant physiquement plusieurs fois dans le programme (par exemple des fonction inlinées, des fcts définies dans différentes bibliothèques dynamiques...).
Je cible plutôt tout public, en tous cas pas l'universitairre.
Ca tombe bien, je n'ai pas la formation qui me permettrait de fournir une réponse un tant soit peu universitaire. C'est rare que ce soit un avantage, j'en profite...
| Bonsoir, | Dans le droit fil de réflexions sur la récursivité, j'ai un souci de | vocabulaire. | Comment nommer de façon simple l'état d'une fonction qui a été appelée et | qui n'est pas encore retournée ? | C'est par exemple l'état de main() pendant toute la durée du programme. | Active, trop ambiguë, pour moi, cela signifie que le code est dedans. | Vivante ? J'aime bien, mais je n'ose pas.
Dans certaines communautés, on parle de « suspendu » (suspended). Notamment, quand on parle de coroutines et d'itérateurs (pas au sens C++).
| Corollaire : à quoi appliquer ce terme ? Quand une fonction n'a pas retourné | et que pour une raison ou une autre elle est appelée à nouveau, je pense en | termes d'instanciation. Le parallélisme est effectivement clair, puiqu'il | s'agit de créer un nouveau jeu de données. Comment appelleriez-vous cette | instance de fonction ? Instance de fonction ?
Yup. Je crois que la norme C++ utilise ce terme au moins une fois quelque part (mais cela n'avait pas de relation avec les templates).
| Bonsoir,
| Dans le droit fil de réflexions sur la récursivité, j'ai un souci de
| vocabulaire.
| Comment nommer de façon simple l'état d'une fonction qui a été appelée et
| qui n'est pas encore retournée ?
| C'est par exemple l'état de main() pendant toute la durée du programme.
| Active, trop ambiguë, pour moi, cela signifie que le code est dedans.
| Vivante ? J'aime bien, mais je n'ose pas.
Dans certaines communautés, on parle de « suspendu » (suspended).
Notamment, quand on parle de coroutines et d'itérateurs (pas au sens C++).
| Corollaire : à quoi appliquer ce terme ? Quand une fonction n'a pas retourné
| et que pour une raison ou une autre elle est appelée à nouveau, je pense en
| termes d'instanciation. Le parallélisme est effectivement clair, puiqu'il
| s'agit de créer un nouveau jeu de données. Comment appelleriez-vous cette
| instance de fonction ? Instance de fonction ?
Yup. Je crois que la norme C++ utilise ce terme au moins une fois
quelque part (mais cela n'avait pas de relation avec les templates).
| Bonsoir, | Dans le droit fil de réflexions sur la récursivité, j'ai un souci de | vocabulaire. | Comment nommer de façon simple l'état d'une fonction qui a été appelée et | qui n'est pas encore retournée ? | C'est par exemple l'état de main() pendant toute la durée du programme. | Active, trop ambiguë, pour moi, cela signifie que le code est dedans. | Vivante ? J'aime bien, mais je n'ose pas.
Dans certaines communautés, on parle de « suspendu » (suspended). Notamment, quand on parle de coroutines et d'itérateurs (pas au sens C++).
| Corollaire : à quoi appliquer ce terme ? Quand une fonction n'a pas retourné | et que pour une raison ou une autre elle est appelée à nouveau, je pense en | termes d'instanciation. Le parallélisme est effectivement clair, puiqu'il | s'agit de créer un nouveau jeu de données. Comment appelleriez-vous cette | instance de fonction ? Instance de fonction ?
Yup. Je crois que la norme C++ utilise ce terme au moins une fois quelque part (mais cela n'avait pas de relation avec les templates).
-- Gaby
Pierre Maurette
Merci à Loïc et Gabriel, vos réponses m'ont aidé à faire le point.
Bon, je partais à l'envers. Pour nommer ce qui est créé à chaque appel de fonction, je choisis "instance". J'ai presque la bénédiction de Gabriel, je ne risque donc plus rien. Le mot français utilisé en informatique est comme de plus en plus souvent une importation d'un terme anglais débouchant, par rapport au dictionnaire, sur un contre-sens. Le terme anglais désigne un "cas" (un cas de choléra est une instance fâcheuse de la maladie choléra), un exemplaire, encore que là on utilise plutôt "copy". En définitive, à partir du mot anglais, nous avons créé un mot français spécifiquement informatique bien précis, mais n'ayant rien à voir avec les sens académiques du même mot. Pour moi, rien de choquant das la phrase "une variable double est une instance du type double". Il s'agit bien entendu d'instances non nommées, mais ce n'est pas grave. il y aura toujours un moyen pour les désigner : la fonnction f()
J'aurais dit incarnation. Et réincarnation si après le retour d'une fonction, elle est à nouveau
appelée ;-)
Instance me ferait plutôt penser à des fonctions existant physiquement plusieurs fois dans le programme (par exemple des fonction inlinées, des fcts définies dans différentes bibliothèques dynamiques...). Une fonction se comporte sur ce plan schématiquement comme une classe : à
chaque nouvelle instance, un jeu de données (variables automatiques, paramètres, et données membres non statiques) est créé, mais dans le cas général, le code non inline n'est pas dupliqué. Le parallèle est fort, s'il n'est bien sûr pas absolu. Une différence fondamentale est que chaque instance de classe a son propre pointeur, au contraire de la fonction. Ce qui semble montrer que la non duplication du code d'une fonction serait dans la norme, et non pas un choix d'implémentation.
Maintenant que la seconde question, celle du nom de la chose, est résolue, la première n'a plus de sens : Entre le moment où la fonction est appelée et celui où elle retourne, une instance existe, point barre. C'est sans doute ce que j'avais en tête avec "vivante".
Bonne nuit,
Pierre
Merci à Loïc et Gabriel, vos réponses m'ont aidé à faire le point.
Bon, je partais à l'envers.
Pour nommer ce qui est créé à chaque appel de fonction, je choisis
"instance".
J'ai presque la bénédiction de Gabriel, je ne risque donc plus rien.
Le mot français utilisé en informatique est comme de plus en plus souvent
une importation d'un terme anglais débouchant, par rapport au dictionnaire,
sur un contre-sens. Le terme anglais désigne un "cas" (un cas de choléra est
une instance fâcheuse de la maladie choléra), un exemplaire, encore que là
on utilise plutôt "copy". En définitive, à partir du mot anglais, nous avons
créé un mot français spécifiquement informatique bien précis, mais n'ayant
rien à voir avec les sens académiques du même mot. Pour moi, rien de
choquant das la phrase "une variable double est une instance du type
double".
Il s'agit bien entendu d'instances non nommées, mais ce n'est pas grave. il
y aura toujours un moyen pour les désigner : la fonnction f()
J'aurais dit incarnation.
Et réincarnation si après le retour d'une fonction, elle est à nouveau
appelée ;-)
Instance me ferait plutôt penser à des
fonctions existant physiquement plusieurs fois dans le programme (par
exemple des fonction inlinées, des fcts définies dans différentes
bibliothèques dynamiques...).
Une fonction se comporte sur ce plan schématiquement comme une classe : à
chaque nouvelle instance, un jeu de données (variables automatiques,
paramètres, et données membres non statiques) est créé, mais dans le cas
général, le code non inline n'est pas dupliqué. Le parallèle est fort, s'il
n'est bien sûr pas absolu.
Une différence fondamentale est que chaque instance de classe a son propre
pointeur, au contraire de la fonction. Ce qui semble montrer que la non
duplication du code d'une fonction serait dans la norme, et non pas un choix
d'implémentation.
Maintenant que la seconde question, celle du nom de la chose, est résolue,
la première n'a plus de sens : Entre le moment où la fonction est appelée et
celui où elle retourne, une instance existe, point barre. C'est sans doute
ce que j'avais en tête avec "vivante".
Merci à Loïc et Gabriel, vos réponses m'ont aidé à faire le point.
Bon, je partais à l'envers. Pour nommer ce qui est créé à chaque appel de fonction, je choisis "instance". J'ai presque la bénédiction de Gabriel, je ne risque donc plus rien. Le mot français utilisé en informatique est comme de plus en plus souvent une importation d'un terme anglais débouchant, par rapport au dictionnaire, sur un contre-sens. Le terme anglais désigne un "cas" (un cas de choléra est une instance fâcheuse de la maladie choléra), un exemplaire, encore que là on utilise plutôt "copy". En définitive, à partir du mot anglais, nous avons créé un mot français spécifiquement informatique bien précis, mais n'ayant rien à voir avec les sens académiques du même mot. Pour moi, rien de choquant das la phrase "une variable double est une instance du type double". Il s'agit bien entendu d'instances non nommées, mais ce n'est pas grave. il y aura toujours un moyen pour les désigner : la fonnction f()
J'aurais dit incarnation. Et réincarnation si après le retour d'une fonction, elle est à nouveau
appelée ;-)
Instance me ferait plutôt penser à des fonctions existant physiquement plusieurs fois dans le programme (par exemple des fonction inlinées, des fcts définies dans différentes bibliothèques dynamiques...). Une fonction se comporte sur ce plan schématiquement comme une classe : à
chaque nouvelle instance, un jeu de données (variables automatiques, paramètres, et données membres non statiques) est créé, mais dans le cas général, le code non inline n'est pas dupliqué. Le parallèle est fort, s'il n'est bien sûr pas absolu. Une différence fondamentale est que chaque instance de classe a son propre pointeur, au contraire de la fonction. Ce qui semble montrer que la non duplication du code d'une fonction serait dans la norme, et non pas un choix d'implémentation.
Maintenant que la seconde question, celle du nom de la chose, est résolue, la première n'a plus de sens : Entre le moment où la fonction est appelée et celui où elle retourne, une instance existe, point barre. C'est sans doute ce que j'avais en tête avec "vivante".
Bonne nuit,
Pierre
kanze
"Pierre Maurette" <mmaauurreettttttee.ppiieerrrree@@ffrreeee.ffrr> wrote in message news:<3fdfc246$0$29073$...
[...]
J'aurais dit incarnation. Et réincarnation si après le retour d'une fonction, elle est à nouveau
appelée ;-)
La réincarnation, c'est quand tu as quitté une fonction, et que tu appelles une autre fonction, qui n'initialise pas ses variables locales, et que tu te rétrouves avec les variables de la fonction que tu as quitté.
Comme technique de programmation, c'est à peu près aussi sûr que ne l'est notre réincarnation à nous.
-- James Kanze GABI Software mailto: Conseils en informatique orientée objet/ http://www.gabi-soft.fr Beratung in objektorientierter Datenverarbeitung 11 rue de Rambouillet, 78460 Chevreuse, France, +33 (0)1 30 23 45 16
"Pierre Maurette" <mmaauurreettttttee.ppiieerrrree@@ffrreeee.ffrr> wrote
in message news:<3fdfc246$0$29073$636a55ce@news.free.fr>...
[...]
J'aurais dit incarnation.
Et réincarnation si après le retour d'une fonction, elle est à nouveau
appelée ;-)
La réincarnation, c'est quand tu as quitté une fonction, et que tu
appelles une autre fonction, qui n'initialise pas ses variables locales,
et que tu te rétrouves avec les variables de la fonction que tu as
quitté.
Comme technique de programmation, c'est à peu près aussi sûr que ne
l'est notre réincarnation à nous.
--
James Kanze GABI Software mailto:kanze@gabi-soft.fr
Conseils en informatique orientée objet/ http://www.gabi-soft.fr
Beratung in objektorientierter Datenverarbeitung
11 rue de Rambouillet, 78460 Chevreuse, France, +33 (0)1 30 23 45 16
"Pierre Maurette" <mmaauurreettttttee.ppiieerrrree@@ffrreeee.ffrr> wrote in message news:<3fdfc246$0$29073$...
[...]
J'aurais dit incarnation. Et réincarnation si après le retour d'une fonction, elle est à nouveau
appelée ;-)
La réincarnation, c'est quand tu as quitté une fonction, et que tu appelles une autre fonction, qui n'initialise pas ses variables locales, et que tu te rétrouves avec les variables de la fonction que tu as quitté.
Comme technique de programmation, c'est à peu près aussi sûr que ne l'est notre réincarnation à nous.
-- James Kanze GABI Software mailto: Conseils en informatique orientée objet/ http://www.gabi-soft.fr Beratung in objektorientierter Datenverarbeitung 11 rue de Rambouillet, 78460 Chevreuse, France, +33 (0)1 30 23 45 16
Marc Boyer
Pierre Maurette wrote:
Bonsoir, Dans le droit fil de réflexions sur la récursivité, j'ai un souci de vocabulaire. Comment nommer de façon simple l'état d'une fonction qui a été appelée et qui n'est pas encore retournée ?
Je dis simplement qu'elle est dans la pile d'appel (ou pile d'exécution). Ca permet en plus d'introduire la notion de profondeur, et ça permet d'expliquer la propagation d'exception.
C'est par exemple l'état de main() pendant toute la durée du programme.
Fond de pile ;-)
Corollaire : à quoi appliquer ce terme ? Quand une fonction n'a pas retourné et que pour une raison ou une autre elle est appelée à nouveau, je pense en termes d'instanciation. Le parallélisme est effectivement clair, puiqu'il s'agit de créer un nouveau jeu de données. Comment appelleriez-vous cette instance de fonction ? Instance de fonction ?
Instance de fonction me semble bien.
thread (ou fil) ne convient pas, puisque le terme évoque l'idée de déroulement (macroscopiquement) simultanée, alors que deux "instances" de n'importe quelle fonction ne sont que "vivantes" en même temps.
Oui, thread, c'est tout à fait différent. Chaque thread possède sa pile d'appel.
Je cible plutôt tout public, en tous cas pas l'universitairre.
Un "tout public" qui programme quand même, non ?
Marc Boyer -- Lying for having sex or lying for making war? Trust US presidents :-(
Pierre Maurette wrote:
Bonsoir,
Dans le droit fil de réflexions sur la récursivité, j'ai un souci de
vocabulaire.
Comment nommer de façon simple l'état d'une fonction qui a été appelée et
qui n'est pas encore retournée ?
Je dis simplement qu'elle est dans la pile d'appel (ou
pile d'exécution). Ca permet en plus d'introduire la
notion de profondeur, et ça permet d'expliquer la propagation
d'exception.
C'est par exemple l'état de main() pendant toute la durée du programme.
Fond de pile ;-)
Corollaire : à quoi appliquer ce terme ? Quand une fonction n'a pas retourné
et que pour une raison ou une autre elle est appelée à nouveau, je pense en
termes d'instanciation. Le parallélisme est effectivement clair, puiqu'il
s'agit de créer un nouveau jeu de données. Comment appelleriez-vous cette
instance de fonction ? Instance de fonction ?
Instance de fonction me semble bien.
thread (ou fil) ne convient
pas, puisque le terme évoque l'idée de déroulement (macroscopiquement)
simultanée, alors que deux "instances" de n'importe quelle fonction ne sont
que "vivantes" en même temps.
Oui, thread, c'est tout à fait différent. Chaque thread possède
sa pile d'appel.
Je cible plutôt tout public, en tous cas pas l'universitairre.
Un "tout public" qui programme quand même, non ?
Marc Boyer
--
Lying for having sex or lying for making war? Trust US presidents :-(
Bonsoir, Dans le droit fil de réflexions sur la récursivité, j'ai un souci de vocabulaire. Comment nommer de façon simple l'état d'une fonction qui a été appelée et qui n'est pas encore retournée ?
Je dis simplement qu'elle est dans la pile d'appel (ou pile d'exécution). Ca permet en plus d'introduire la notion de profondeur, et ça permet d'expliquer la propagation d'exception.
C'est par exemple l'état de main() pendant toute la durée du programme.
Fond de pile ;-)
Corollaire : à quoi appliquer ce terme ? Quand une fonction n'a pas retourné et que pour une raison ou une autre elle est appelée à nouveau, je pense en termes d'instanciation. Le parallélisme est effectivement clair, puiqu'il s'agit de créer un nouveau jeu de données. Comment appelleriez-vous cette instance de fonction ? Instance de fonction ?
Instance de fonction me semble bien.
thread (ou fil) ne convient pas, puisque le terme évoque l'idée de déroulement (macroscopiquement) simultanée, alors que deux "instances" de n'importe quelle fonction ne sont que "vivantes" en même temps.
Oui, thread, c'est tout à fait différent. Chaque thread possède sa pile d'appel.
Je cible plutôt tout public, en tous cas pas l'universitairre.
Un "tout public" qui programme quand même, non ?
Marc Boyer -- Lying for having sex or lying for making war? Trust US presidents :-(
Pierre Maurette
a écrit [...]
La réincarnation, c'est quand tu as quitté une fonction, et que tu appelles une autre fonction, qui n'initialise pas ses variables locales, et que tu te rétrouves avec les variables de la fonction que tu as quitté.
Comme technique de programmation, c'est à peu près aussi sûr que ne l'est notre réincarnation à nous. De la métempsychose au service de la programmation !
Sur la "technique de programmation", je me souviens d'un fil là-dessus il y a quelque temps (ici ou chez les collègues du --). Le gars partait du principe que les variables locales étaient bien "quelque part", et qu'en s'y prenant suffisamment tôt, on devait pouvoir les "attraper". (intérêt ?). En fait, juste après la sortie de la fonction , et non juste avant le retour dans l'appelant (nuance importante,il peut y avoir quelque chose entre les deux) les variables sont dans le futur le plus immédiat de la pile, une zone extrémement dangeureuse. Pierre
<kanze@gabi-soft.fr> a écrit
[...]
La réincarnation, c'est quand tu as quitté une fonction, et que tu
appelles une autre fonction, qui n'initialise pas ses variables locales,
et que tu te rétrouves avec les variables de la fonction que tu as
quitté.
Comme technique de programmation, c'est à peu près aussi sûr que ne
l'est notre réincarnation à nous.
De la métempsychose au service de la programmation !
Sur la "technique de programmation", je me souviens d'un fil là-dessus il y
a quelque temps (ici ou chez les collègues du --). Le gars partait du
principe que les variables locales étaient bien "quelque part", et qu'en s'y
prenant suffisamment tôt, on devait pouvoir les "attraper". (intérêt ?). En
fait, juste après la sortie de la fonction , et non juste avant le retour
dans l'appelant (nuance importante,il peut y avoir quelque chose entre les
deux) les variables sont dans le futur le plus immédiat de la pile, une zone
extrémement dangeureuse.
Pierre
La réincarnation, c'est quand tu as quitté une fonction, et que tu appelles une autre fonction, qui n'initialise pas ses variables locales, et que tu te rétrouves avec les variables de la fonction que tu as quitté.
Comme technique de programmation, c'est à peu près aussi sûr que ne l'est notre réincarnation à nous. De la métempsychose au service de la programmation !
Sur la "technique de programmation", je me souviens d'un fil là-dessus il y a quelque temps (ici ou chez les collègues du --). Le gars partait du principe que les variables locales étaient bien "quelque part", et qu'en s'y prenant suffisamment tôt, on devait pouvoir les "attraper". (intérêt ?). En fait, juste après la sortie de la fonction , et non juste avant le retour dans l'appelant (nuance importante,il peut y avoir quelque chose entre les deux) les variables sont dans le futur le plus immédiat de la pile, une zone extrémement dangeureuse. Pierre
Pierre Maurette
"Marc Boyer" a écrit [...]
C'est par exemple l'état de main() pendant toute la durée du programme.
Fond de pile ;-) Oui. Je représente toutes les piles comme montantes. On a un accès immédiat
au sommet de la pile. Même si quand la pile monte, les adresses diminuent. J'ai remarqué qu'Intel dans ses docs représente la pile croissant vers le bas, mais parle de top of stack. Je trouve en effet que c'est un peu hard d'expliquer à un gars que la pile, c'est comme une pile d'assiettes, etg juste après lui demander d'imaginer une pile d'assiette qui descendrait du plafond.
Un "tout public" qui programme quand même, non ? Si je ne l'en dégoûte pas ;-)
Pierre
"Marc Boyer" <Marc.Boyer@enseeiht.yahoo.fr.invalid> a écrit
[...]
C'est par exemple l'état de main() pendant toute la durée du programme.
Fond de pile ;-)
Oui. Je représente toutes les piles comme montantes. On a un accès immédiat
au sommet de la pile. Même si quand la pile monte, les adresses diminuent.
J'ai remarqué qu'Intel dans ses docs représente la pile croissant vers le
bas, mais parle de top of stack.
Je trouve en effet que c'est un peu hard d'expliquer à un gars que la pile,
c'est comme une pile d'assiettes, etg juste après lui demander d'imaginer
une pile d'assiette qui descendrait du plafond.
Un "tout public" qui programme quand même, non ?
Si je ne l'en dégoûte pas ;-)
C'est par exemple l'état de main() pendant toute la durée du programme.
Fond de pile ;-) Oui. Je représente toutes les piles comme montantes. On a un accès immédiat
au sommet de la pile. Même si quand la pile monte, les adresses diminuent. J'ai remarqué qu'Intel dans ses docs représente la pile croissant vers le bas, mais parle de top of stack. Je trouve en effet que c'est un peu hard d'expliquer à un gars que la pile, c'est comme une pile d'assiettes, etg juste après lui demander d'imaginer une pile d'assiette qui descendrait du plafond.
Un "tout public" qui programme quand même, non ? Si je ne l'en dégoûte pas ;-)
Pierre
Marc Boyer
Pierre Maurette wrote:
"Marc Boyer" a écrit [...]
C'est par exemple l'état de main() pendant toute la durée du programme.
Fond de pile ;-) Oui. Je représente toutes les piles comme montantes. On a un accès immédiat
au sommet de la pile. Même si quand la pile monte, les adresses diminuent.
Tu dois leur parler des adresses de la pile ?
Je trouve en effet que c'est un peu hard d'expliquer à un gars que la pile, c'est comme une pile d'assiettes, etg juste après lui demander d'imaginer une pile d'assiette qui descendrait du plafond.
Ben moi, je lui explique pas. Il apprend à programmer sans savoir comment est implanté la pile sur son OS/proc. Si je dois expliquer que la pile descend, ce sera au moins 12 mois après son premier cours de prog. D'ailleurs, sur fclc++, une pile d'appel ne descend ni ne monte: c'est dépendant de l'implémentation.
Marc Boyer -- Lying for having sex or lying for making war? Trust US presidents :-(
Pierre Maurette wrote:
"Marc Boyer" <Marc.Boyer@enseeiht.yahoo.fr.invalid> a écrit
[...]
C'est par exemple l'état de main() pendant toute la durée du programme.
Fond de pile ;-)
Oui. Je représente toutes les piles comme montantes. On a un accès immédiat
au sommet de la pile. Même si quand la pile monte, les adresses diminuent.
Tu dois leur parler des adresses de la pile ?
Je trouve en effet que c'est un peu hard d'expliquer à un gars que la pile,
c'est comme une pile d'assiettes, etg juste après lui demander d'imaginer
une pile d'assiette qui descendrait du plafond.
Ben moi, je lui explique pas. Il apprend à programmer sans
savoir comment est implanté la pile sur son OS/proc.
Si je dois expliquer que la pile descend, ce sera au moins
12 mois après son premier cours de prog. D'ailleurs, sur
fclc++, une pile d'appel ne descend ni ne monte: c'est dépendant
de l'implémentation.
Marc Boyer
--
Lying for having sex or lying for making war? Trust US presidents :-(
C'est par exemple l'état de main() pendant toute la durée du programme.
Fond de pile ;-) Oui. Je représente toutes les piles comme montantes. On a un accès immédiat
au sommet de la pile. Même si quand la pile monte, les adresses diminuent.
Tu dois leur parler des adresses de la pile ?
Je trouve en effet que c'est un peu hard d'expliquer à un gars que la pile, c'est comme une pile d'assiettes, etg juste après lui demander d'imaginer une pile d'assiette qui descendrait du plafond.
Ben moi, je lui explique pas. Il apprend à programmer sans savoir comment est implanté la pile sur son OS/proc. Si je dois expliquer que la pile descend, ce sera au moins 12 mois après son premier cours de prog. D'ailleurs, sur fclc++, une pile d'appel ne descend ni ne monte: c'est dépendant de l'implémentation.
Marc Boyer -- Lying for having sex or lying for making war? Trust US presidents :-(
Raphael TOSTO
Oui. Je représente toutes les piles comme montantes. On a un accès immédiat
au sommet de la pile. Même si quand la pile monte, les adresses diminuent. J'ai remarqué qu'Intel dans ses docs représente la pile croissant vers le bas, mais parle de top of stack. Je trouve en effet que c'est un peu hard d'expliquer à un gars que la pile,
c'est comme une pile d'assiettes, etg juste après lui demander d'imaginer une pile d'assiette qui descendrait du plafond.
Le <Sp> monte quand il est décrémenté, à chaque <push>. C'est la raison de présenter la pile croissant vers le bas.
Et la pile d'assiettes monte et descend suivant les lois de la gravitation :-)
Oui. Je représente toutes les piles comme montantes. On a un accès
immédiat
au sommet de la pile. Même si quand la pile monte, les adresses diminuent.
J'ai remarqué qu'Intel dans ses docs représente la pile croissant vers le
bas, mais parle de top of stack.
Je trouve en effet que c'est un peu hard d'expliquer à un gars que la
pile,
c'est comme une pile d'assiettes, etg juste après lui demander d'imaginer
une pile d'assiette qui descendrait du plafond.
Oui. Je représente toutes les piles comme montantes. On a un accès immédiat
au sommet de la pile. Même si quand la pile monte, les adresses diminuent. J'ai remarqué qu'Intel dans ses docs représente la pile croissant vers le bas, mais parle de top of stack. Je trouve en effet que c'est un peu hard d'expliquer à un gars que la pile,
c'est comme une pile d'assiettes, etg juste après lui demander d'imaginer une pile d'assiette qui descendrait du plafond.
Le <Sp> monte quand il est décrémenté, à chaque <push>. C'est la raison de présenter la pile croissant vers le bas.
Et la pile d'assiettes monte et descend suivant les lois de la gravitation :-)
Pierre Maurette
"Marc Boyer" a écrit
Tu dois leur parler des adresses de la pile ? Moi pas parler, moi écrire. Je me suis un peu occupé d'assembleur.
Ceci dit, même en assembleur, je défends explicitement l'idée que moins on pense adresses dans la pile, mieux c'est. En IA32, PUSH, POP, CALL, RET et associés nous isolent sans problème de ces adresses. ENTER et LEAVE vont plus loin en permettant de faciliter (là, j'ai parfois des doutes) l'implémentation des stack frames et donc de la réentrance, demande des langages évolués, dont C et C++ (et Pascal). C'est Intel qui présente ainsi ces instructions. Comme ça, on n'est pas 100% HS. Il y a un équivalent chez Motorola, et sans doute ailleurs. Reste le problème de l'accès direct aux données de la pile (pas par PUSH/POP). C'est en général en [EBP + n], qui ne change pas au contraire de [ESP + m]. Un simple assembleur symbolique permet déjà beaucoup, un bon macro-assembleur permet lui de ne jamais voir la variable autrement que par son nom.
Ben moi, je lui explique pas. Il apprend à programmer sans savoir comment est implanté la pile sur son OS/proc. Oui. De plus, pas de référence explicite à la pile d'un quelconque
processeur dans la norme. Mais prenons un prof. Fatalement, un jour, peut-être à l'occasion d'une présentation d'un appel récursif, quelques élèves manifesteront leur incompréhension. Les autres élèves n'étant majoritairement pas ceux qui ont compris, mais ceux qui s'en fichent. Implantation unique du code, plusieurs jeux de données, ne revenons pas là-dessus, les causes de ce flou sont connues. Ou alors, notre prof aura donné en exercice une fonction récursive. Il passera rapidement sur les excellentes solutions proposées par ceux parmi les élèves (de futurs commerciauux) qui auront réussi à se faire coder le bouzin sur fclc ou fclc++. Et il tombera une fois de plus sur le troupeau des honnêtes. Certains auront codé un truc invraisemblable, truffé de static. Ça marche vaguement au premier appel, puis plante ou renvoie n'importe quoi au second. Forcément. Et de plus, si un appel récursif par définition figure dans la fonction, l'algo ne l'est pas. Donc, incompréhension. Donc, explication. Prof attaque, la norme, conservation des variables automatiques d'un appel à l'autre, etc. X% de réussite. Donc (100-X)% d'échecs. Ceux qui disent en boucle "oui, mais comment le programme retrouve ses variables ? c'est pas possible, votre machin". Ce sera alors le bon moment de passer au tableau, et d'attaquer : "Bon, nous allons voir en détail comment ça POURRAIT se passer sur une machine particulière. etc.". Bien entendu, il serait tout à fait criminel à ce moment-là de parler de pile qui pousse à l'envers ;-).
Pierre
"Marc Boyer" <Marc.Boyer@enseeiht.yahoo.fr.invalid> a écrit
Tu dois leur parler des adresses de la pile ?
Moi pas parler, moi écrire. Je me suis un peu occupé d'assembleur.
Ceci dit, même en assembleur, je défends explicitement l'idée que moins on
pense adresses dans la pile, mieux c'est.
En IA32, PUSH, POP, CALL, RET et associés nous isolent sans problème de ces
adresses. ENTER et LEAVE vont plus loin en permettant de faciliter (là, j'ai
parfois des doutes) l'implémentation des stack frames et donc de la
réentrance, demande des langages évolués, dont C et C++ (et Pascal). C'est
Intel qui présente ainsi ces instructions. Comme ça, on n'est pas 100% HS.
Il y a un équivalent chez Motorola, et sans doute ailleurs.
Reste le problème de l'accès direct aux données de la pile (pas par
PUSH/POP). C'est en général en [EBP + n], qui ne change pas au contraire de
[ESP + m]. Un simple assembleur symbolique permet déjà beaucoup, un bon
macro-assembleur permet lui de ne jamais voir la variable autrement que par
son nom.
Ben moi, je lui explique pas. Il apprend à programmer sans
savoir comment est implanté la pile sur son OS/proc.
Oui. De plus, pas de référence explicite à la pile d'un quelconque
processeur dans la norme.
Mais prenons un prof. Fatalement, un jour, peut-être à l'occasion d'une
présentation d'un appel récursif, quelques élèves manifesteront leur
incompréhension. Les autres élèves n'étant majoritairement pas ceux qui ont
compris, mais ceux qui s'en fichent. Implantation unique du code, plusieurs
jeux de données, ne revenons pas là-dessus, les causes de ce flou sont
connues.
Ou alors, notre prof aura donné en exercice une fonction récursive. Il
passera rapidement sur les excellentes solutions proposées par ceux parmi
les élèves (de futurs commerciauux) qui auront réussi à se faire coder le
bouzin sur fclc ou fclc++. Et il tombera une fois de plus sur le troupeau
des honnêtes. Certains auront codé un truc invraisemblable, truffé de
static. Ça marche vaguement au premier appel, puis plante ou renvoie
n'importe quoi au second. Forcément. Et de plus, si un appel récursif par
définition figure dans la fonction, l'algo ne l'est pas. Donc,
incompréhension. Donc, explication.
Prof attaque, la norme, conservation des variables automatiques d'un appel à
l'autre, etc. X% de réussite. Donc (100-X)% d'échecs. Ceux qui disent en
boucle "oui, mais comment le programme retrouve ses variables ? c'est pas
possible, votre machin".
Ce sera alors le bon moment de passer au tableau, et d'attaquer : "Bon, nous
allons voir en détail comment ça POURRAIT se passer sur une machine
particulière. etc.".
Bien entendu, il serait tout à fait criminel à ce moment-là de parler de
pile qui pousse à l'envers ;-).
Tu dois leur parler des adresses de la pile ? Moi pas parler, moi écrire. Je me suis un peu occupé d'assembleur.
Ceci dit, même en assembleur, je défends explicitement l'idée que moins on pense adresses dans la pile, mieux c'est. En IA32, PUSH, POP, CALL, RET et associés nous isolent sans problème de ces adresses. ENTER et LEAVE vont plus loin en permettant de faciliter (là, j'ai parfois des doutes) l'implémentation des stack frames et donc de la réentrance, demande des langages évolués, dont C et C++ (et Pascal). C'est Intel qui présente ainsi ces instructions. Comme ça, on n'est pas 100% HS. Il y a un équivalent chez Motorola, et sans doute ailleurs. Reste le problème de l'accès direct aux données de la pile (pas par PUSH/POP). C'est en général en [EBP + n], qui ne change pas au contraire de [ESP + m]. Un simple assembleur symbolique permet déjà beaucoup, un bon macro-assembleur permet lui de ne jamais voir la variable autrement que par son nom.
Ben moi, je lui explique pas. Il apprend à programmer sans savoir comment est implanté la pile sur son OS/proc. Oui. De plus, pas de référence explicite à la pile d'un quelconque
processeur dans la norme. Mais prenons un prof. Fatalement, un jour, peut-être à l'occasion d'une présentation d'un appel récursif, quelques élèves manifesteront leur incompréhension. Les autres élèves n'étant majoritairement pas ceux qui ont compris, mais ceux qui s'en fichent. Implantation unique du code, plusieurs jeux de données, ne revenons pas là-dessus, les causes de ce flou sont connues. Ou alors, notre prof aura donné en exercice une fonction récursive. Il passera rapidement sur les excellentes solutions proposées par ceux parmi les élèves (de futurs commerciauux) qui auront réussi à se faire coder le bouzin sur fclc ou fclc++. Et il tombera une fois de plus sur le troupeau des honnêtes. Certains auront codé un truc invraisemblable, truffé de static. Ça marche vaguement au premier appel, puis plante ou renvoie n'importe quoi au second. Forcément. Et de plus, si un appel récursif par définition figure dans la fonction, l'algo ne l'est pas. Donc, incompréhension. Donc, explication. Prof attaque, la norme, conservation des variables automatiques d'un appel à l'autre, etc. X% de réussite. Donc (100-X)% d'échecs. Ceux qui disent en boucle "oui, mais comment le programme retrouve ses variables ? c'est pas possible, votre machin". Ce sera alors le bon moment de passer au tableau, et d'attaquer : "Bon, nous allons voir en détail comment ça POURRAIT se passer sur une machine particulière. etc.". Bien entendu, il serait tout à fait criminel à ce moment-là de parler de pile qui pousse à l'envers ;-).
