j'apprends C++, et je suis confronté à ce pb : passer un tableau à une
fonction, voilà un code sans utilité mais qui permet de mettre mon pb en
avant : je reçois le message d'erreur suivant: Unresolved external
'ChangerVal(int)' referenced from module prog1.cpp
#include <iostream.h>
#include <conio.h>
| > > La connaissance du fonctionnement de la pile me parait indispensable | > > pour comprendre les differents types de passage d'arguments. | > | > Le passage des arguments est une fonctionalite abstraite definie par | > le langage, la maniere de l'implementer sur ton architecture n'a | > aucune importance. Et je ne vois pas l'utilite d'une pile pour passer | > les arguments, on essaie plutot meme de l'eviter. (Je vois l'utilite | > de la pile pour garder un contexte quand des appels recursifs sont | > possibles, mais tous les langages n'autorisent pas le recursivite). | > | | Les arguments des fonctions passent TOUJOURS par la pile.
par decret de ?
| Je suis surpris qu'un programmeur C++ ne sache pas ca.
Ce qui est surprenant, c'est la force avec laquelle tu assènes cette contre-vérité.
Ce qui est surprenant c'est la constante et consternante niaiserie de tes reponses.
Ils passent par ou les arguments?
MB
"Gabriel Dos Reis" <dosreis@cmla.ens-cachan.fr> a écrit dans le message
news: flwuboygl9.fsf@sel.cmla.ens-cachan.fr...
"M.B." <mbinder@magicnet.com> writes:
[...]
| > > La connaissance du fonctionnement de la pile me parait indispensable
| > > pour comprendre les differents types de passage d'arguments.
| >
| > Le passage des arguments est une fonctionalite abstraite definie par
| > le langage, la maniere de l'implementer sur ton architecture n'a
| > aucune importance. Et je ne vois pas l'utilite d'une pile pour passer
| > les arguments, on essaie plutot meme de l'eviter. (Je vois l'utilite
| > de la pile pour garder un contexte quand des appels recursifs sont
| > possibles, mais tous les langages n'autorisent pas le recursivite).
| >
|
| Les arguments des fonctions passent TOUJOURS par la pile.
par decret de ?
| Je suis surpris qu'un programmeur C++ ne sache pas ca.
Ce qui est surprenant, c'est la force avec laquelle tu assènes cette
contre-vérité.
Ce qui est surprenant c'est la constante et consternante niaiserie
de tes reponses.
| > > La connaissance du fonctionnement de la pile me parait indispensable | > > pour comprendre les differents types de passage d'arguments. | > | > Le passage des arguments est une fonctionalite abstraite definie par | > le langage, la maniere de l'implementer sur ton architecture n'a | > aucune importance. Et je ne vois pas l'utilite d'une pile pour passer | > les arguments, on essaie plutot meme de l'eviter. (Je vois l'utilite | > de la pile pour garder un contexte quand des appels recursifs sont | > possibles, mais tous les langages n'autorisent pas le recursivite). | > | | Les arguments des fonctions passent TOUJOURS par la pile.
par decret de ?
| Je suis surpris qu'un programmeur C++ ne sache pas ca.
Ce qui est surprenant, c'est la force avec laquelle tu assènes cette contre-vérité.
Ce qui est surprenant c'est la constante et consternante niaiserie de tes reponses.
Ils passent par ou les arguments?
MB
DG
"M.B." writes:
Dans tous les cas, le processeur empile les arguments, fait au saut a la fonction appelée qui depile, execute, depile l'adresse de retour et resaute a l'appelant.
C'est là que je suis pas d'accord, selon moi ça se passe plutôt comme ça dans le cas général :
- Mise des arguments sur la pile _ou_ dans des registres (dépend du nombre d'argument, de la «pression» sur les registres, du processeur, du compilo... ) ; - Saut à la fonction ; - Création de la frame (sauvegarde du stack pointer (SP); SP <- FP (frame pointer)) ; - Récupération des arguments dans la pile _ou_ dans les registres ; - Exécution du corps de la fonction ; - Rangement du résultat de la fonction (le cas échéant) dans la pile ou dans un registre ; - Remise de la frame dans son état initial ( FP <- SP ; SP <- savegarde du SP) ; - Retour à l'adresse de l'appelant + taille de l'exécution d'appel ;
Voir un cours d'electronique numerique de niveau DUT ou maitrise. Ou les bases de l'Assembleur.
Pense aussi à aller voir un bon cours de compilation...
"M.B." <mbinder@magicnet.com> writes:
Dans tous les cas, le processeur empile les arguments,
fait au saut a la fonction appelée qui depile, execute,
depile l'adresse de retour et resaute a l'appelant.
C'est là que je suis pas d'accord, selon moi ça se passe plutôt comme
ça dans le cas général :
- Mise des arguments sur la pile _ou_ dans des registres (dépend du
nombre d'argument, de la «pression» sur les registres, du processeur,
du compilo... ) ;
- Saut à la fonction ;
- Création de la frame (sauvegarde du stack pointer (SP); SP <- FP
(frame pointer)) ;
- Récupération des arguments dans la pile _ou_ dans les registres ;
- Exécution du corps de la fonction ;
- Rangement du résultat de la fonction (le cas échéant) dans la pile
ou dans un registre ;
- Remise de la frame dans son état initial ( FP <- SP ; SP <-
savegarde du SP) ;
- Retour à l'adresse de l'appelant + taille de l'exécution d'appel ;
Voir un cours d'electronique numerique de niveau DUT ou
maitrise. Ou les bases de l'Assembleur.
Pense aussi à aller voir un bon cours de compilation...
Dans tous les cas, le processeur empile les arguments, fait au saut a la fonction appelée qui depile, execute, depile l'adresse de retour et resaute a l'appelant.
C'est là que je suis pas d'accord, selon moi ça se passe plutôt comme ça dans le cas général :
- Mise des arguments sur la pile _ou_ dans des registres (dépend du nombre d'argument, de la «pression» sur les registres, du processeur, du compilo... ) ; - Saut à la fonction ; - Création de la frame (sauvegarde du stack pointer (SP); SP <- FP (frame pointer)) ; - Récupération des arguments dans la pile _ou_ dans les registres ; - Exécution du corps de la fonction ; - Rangement du résultat de la fonction (le cas échéant) dans la pile ou dans un registre ; - Remise de la frame dans son état initial ( FP <- SP ; SP <- savegarde du SP) ; - Retour à l'adresse de l'appelant + taille de l'exécution d'appel ;
Voir un cours d'electronique numerique de niveau DUT ou maitrise. Ou les bases de l'Assembleur.
Pense aussi à aller voir un bon cours de compilation...
M.B.
"DG" a écrit dans le message news:
"M.B." writes:
Dans tous les cas, le processeur empile les arguments, fait au saut a la fonction appelée qui depile, execute, depile l'adresse de retour et resaute a l'appelant.
C'est là que je suis pas d'accord, selon moi ça se passe plutôt comme ça dans le cas général :
- Mise des arguments sur la pile _ou_ dans des registres (dépend du nombre d'argument, de la «pression» sur les registres, du processeur, du compilo... ) ; - Saut à la fonction ; - Création de la frame (sauvegarde du stack pointer (SP); SP <- FP (frame pointer)) ; - Récupération des arguments dans la pile _ou_ dans les registres ; - Exécution du corps de la fonction ; - Rangement du résultat de la fonction (le cas échéant) dans la pile ou dans un registre ; - Remise de la frame dans son état initial ( FP <- SP ; SP <- savegarde du SP) ; - Retour à l'adresse de l'appelant + taille de l'exécution d'appel ;
Ben oui, on est d'accord, si tu veux approfondir.
MB
"DG" <dany42NOSPAM@free.fr> a écrit dans le message news:
86smmcu8hl.fsf@macphisto.homeunix.org...
"M.B." <mbinder@magicnet.com> writes:
Dans tous les cas, le processeur empile les arguments,
fait au saut a la fonction appelée qui depile, execute,
depile l'adresse de retour et resaute a l'appelant.
C'est là que je suis pas d'accord, selon moi ça se passe plutôt comme
ça dans le cas général :
- Mise des arguments sur la pile _ou_ dans des registres (dépend du
nombre d'argument, de la «pression» sur les registres, du processeur,
du compilo... ) ;
- Saut à la fonction ;
- Création de la frame (sauvegarde du stack pointer (SP); SP <- FP
(frame pointer)) ;
- Récupération des arguments dans la pile _ou_ dans les registres ;
- Exécution du corps de la fonction ;
- Rangement du résultat de la fonction (le cas échéant) dans la pile
ou dans un registre ;
- Remise de la frame dans son état initial ( FP <- SP ; SP <-
savegarde du SP) ;
- Retour à l'adresse de l'appelant + taille de l'exécution d'appel ;
Dans tous les cas, le processeur empile les arguments, fait au saut a la fonction appelée qui depile, execute, depile l'adresse de retour et resaute a l'appelant.
C'est là que je suis pas d'accord, selon moi ça se passe plutôt comme ça dans le cas général :
- Mise des arguments sur la pile _ou_ dans des registres (dépend du nombre d'argument, de la «pression» sur les registres, du processeur, du compilo... ) ; - Saut à la fonction ; - Création de la frame (sauvegarde du stack pointer (SP); SP <- FP (frame pointer)) ; - Récupération des arguments dans la pile _ou_ dans les registres ; - Exécution du corps de la fonction ; - Rangement du résultat de la fonction (le cas échéant) dans la pile ou dans un registre ; - Remise de la frame dans son état initial ( FP <- SP ; SP <- savegarde du SP) ; - Retour à l'adresse de l'appelant + taille de l'exécution d'appel ;
Ben oui, on est d'accord, si tu veux approfondir.
MB
Jonathan Mcdougall
[...]
| > > La connaissance du fonctionnement de la pile me parait indispensable
| > > pour comprendre les differents types de passage d'arguments. | > | > Le passage des arguments est une fonctionalite abstraite definie par | > le langage, la maniere de l'implementer sur ton architecture n'a | > aucune importance. Et je ne vois pas l'utilite d'une pile pour passer
| > les arguments, on essaie plutot meme de l'eviter. (Je vois l'utilite
| > de la pile pour garder un contexte quand des appels recursifs sont | > possibles, mais tous les langages n'autorisent pas le recursivite). | > | | Les arguments des fonctions passent TOUJOURS par la pile.
par decret de ?
| Je suis surpris qu'un programmeur C++ ne sache pas ca.
Ce qui est surprenant, c'est la force avec laquelle tu assènes cette contre-vérité.
Ce qui est surprenant c'est la constante et consternante niaiserie de tes reponses.
Moi aussi, mais c'est hors-sujet ici.
Ils passent par ou les arguments?
Ça dépend de ton implémentation. Je me souviens d'un ancien ordinateur où c'était un petit noir qui courait à l'intérieur, mais ça fait bien longtemps, je peux me tromper.
Jonathan
[...]
| > > La connaissance du fonctionnement de la pile me parait
indispensable
| > > pour comprendre les differents types de passage d'arguments.
| >
| > Le passage des arguments est une fonctionalite abstraite definie par
| > le langage, la maniere de l'implementer sur ton architecture n'a
| > aucune importance. Et je ne vois pas l'utilite d'une pile pour
passer
| > les arguments, on essaie plutot meme de l'eviter. (Je vois
l'utilite
| > de la pile pour garder un contexte quand des appels recursifs sont
| > possibles, mais tous les langages n'autorisent pas le recursivite).
| >
|
| Les arguments des fonctions passent TOUJOURS par la pile.
par decret de ?
| Je suis surpris qu'un programmeur C++ ne sache pas ca.
Ce qui est surprenant, c'est la force avec laquelle tu assènes cette
contre-vérité.
Ce qui est surprenant c'est la constante et consternante niaiserie
de tes reponses.
Moi aussi, mais c'est hors-sujet ici.
Ils passent par ou les arguments?
Ça dépend de ton implémentation. Je me souviens d'un ancien ordinateur
où c'était un petit noir qui courait à l'intérieur, mais ça fait bien
longtemps, je peux me tromper.
| > > La connaissance du fonctionnement de la pile me parait indispensable
| > > pour comprendre les differents types de passage d'arguments. | > | > Le passage des arguments est une fonctionalite abstraite definie par | > le langage, la maniere de l'implementer sur ton architecture n'a | > aucune importance. Et je ne vois pas l'utilite d'une pile pour passer
| > les arguments, on essaie plutot meme de l'eviter. (Je vois l'utilite
| > de la pile pour garder un contexte quand des appels recursifs sont | > possibles, mais tous les langages n'autorisent pas le recursivite). | > | | Les arguments des fonctions passent TOUJOURS par la pile.
par decret de ?
| Je suis surpris qu'un programmeur C++ ne sache pas ca.
Ce qui est surprenant, c'est la force avec laquelle tu assènes cette contre-vérité.
Ce qui est surprenant c'est la constante et consternante niaiserie de tes reponses.
Moi aussi, mais c'est hors-sujet ici.
Ils passent par ou les arguments?
Ça dépend de ton implémentation. Je me souviens d'un ancien ordinateur où c'était un petit noir qui courait à l'intérieur, mais ça fait bien longtemps, je peux me tromper.
Jonathan
DG
"M.B." writes:
"DG" a écrit dans le message news:
"M.B." writes:
Dans tous les cas, le processeur empile les arguments, fait au saut a la fonction appelée qui depile, execute, depile l'adresse de retour et resaute a l'appelant.
C'est là que je suis pas d'accord, selon moi ça se passe plutôt comme ça dans le cas général :
- Mise des arguments sur la pile _ou_ dans des registres (dépend du nombre d'argument, de la «pression» sur les registres, du processeur, du compilo... ) ; - Saut à la fonction ; - Création de la frame (sauvegarde du stack pointer (SP); SP <- FP (frame pointer)) ; - Récupération des arguments dans la pile _ou_ dans les registres ; - Exécution du corps de la fonction ; - Rangement du résultat de la fonction (le cas échéant) dans la pile ou dans un registre ; - Remise de la frame dans son état initial ( FP <- SP ; SP <- savegarde du SP) ; - Retour à l'adresse de l'appelant + taille de l'exécution d'appel ;
Ben oui, on est d'accord, si tu veux approfondir.
Dans ce cas là tu contredis avec ce que tu disais tout à l'heure à savoir que les arguments sont _toujours_ passés sur la pile ; donc oui on est d'accord maintenant :-).
"M.B." <mbinder@magicnet.com> writes:
"DG" <dany42NOSPAM@free.fr> a écrit dans le message news:
86smmcu8hl.fsf@macphisto.homeunix.org...
"M.B." <mbinder@magicnet.com> writes:
Dans tous les cas, le processeur empile les arguments,
fait au saut a la fonction appelée qui depile, execute,
depile l'adresse de retour et resaute a l'appelant.
C'est là que je suis pas d'accord, selon moi ça se passe plutôt comme
ça dans le cas général :
- Mise des arguments sur la pile _ou_ dans des registres (dépend du
nombre d'argument, de la «pression» sur les registres, du processeur,
du compilo... ) ;
- Saut à la fonction ;
- Création de la frame (sauvegarde du stack pointer (SP); SP <- FP
(frame pointer)) ;
- Récupération des arguments dans la pile _ou_ dans les registres ;
- Exécution du corps de la fonction ;
- Rangement du résultat de la fonction (le cas échéant) dans la pile
ou dans un registre ;
- Remise de la frame dans son état initial ( FP <- SP ; SP <-
savegarde du SP) ;
- Retour à l'adresse de l'appelant + taille de l'exécution d'appel ;
Ben oui, on est d'accord, si tu veux approfondir.
Dans ce cas là tu contredis avec ce que tu disais tout à l'heure à savoir
que les arguments sont _toujours_ passés sur la pile ; donc oui on est
d'accord maintenant :-).
Dans tous les cas, le processeur empile les arguments, fait au saut a la fonction appelée qui depile, execute, depile l'adresse de retour et resaute a l'appelant.
C'est là que je suis pas d'accord, selon moi ça se passe plutôt comme ça dans le cas général :
- Mise des arguments sur la pile _ou_ dans des registres (dépend du nombre d'argument, de la «pression» sur les registres, du processeur, du compilo... ) ; - Saut à la fonction ; - Création de la frame (sauvegarde du stack pointer (SP); SP <- FP (frame pointer)) ; - Récupération des arguments dans la pile _ou_ dans les registres ; - Exécution du corps de la fonction ; - Rangement du résultat de la fonction (le cas échéant) dans la pile ou dans un registre ; - Remise de la frame dans son état initial ( FP <- SP ; SP <- savegarde du SP) ; - Retour à l'adresse de l'appelant + taille de l'exécution d'appel ;
Ben oui, on est d'accord, si tu veux approfondir.
Dans ce cas là tu contredis avec ce que tu disais tout à l'heure à savoir que les arguments sont _toujours_ passés sur la pile ; donc oui on est d'accord maintenant :-).
M.B.
"DG" a écrit dans le message news:
"M.B." writes:
"DG" a écrit dans le message news:
"M.B." writes:
Dans tous les cas, le processeur empile les arguments, fait au saut a la fonction appelée qui depile, execute, depile l'adresse de retour et resaute a l'appelant.
C'est là que je suis pas d'accord, selon moi ça se passe plutôt comme ça dans le cas général :
- Mise des arguments sur la pile _ou_ dans des registres (dépend du nombre d'argument, de la «pression» sur les registres, du processeur, du compilo... ) ; - Saut à la fonction ; - Création de la frame (sauvegarde du stack pointer (SP); SP <- FP (frame pointer)) ; - Récupération des arguments dans la pile _ou_ dans les registres ; - Exécution du corps de la fonction ; - Rangement du résultat de la fonction (le cas échéant) dans la pile ou dans un registre ; - Remise de la frame dans son état initial ( FP <- SP ; SP <- savegarde du SP) ; - Retour à l'adresse de l'appelant + taille de l'exécution d'appel ;
Ben oui, on est d'accord, si tu veux approfondir.
Dans ce cas là tu contredis avec ce que tu disais tout à l'heure à savoir que les arguments sont _toujours_ passés sur la pile ; donc oui on est d'accord maintenant :-).
Que ce soit la pile ou un registre specialisé dans un processeur particulier, ca ne change rien.
Mon propos est de dire qu'il vaut mieux connaitre ces mecanismes, ca aide a comprendre certains effets pervers de programmes en phase de debug.
MB
"DG" <dany42NOSPAM@free.fr> a écrit dans le message news:
86oex0u82u.fsf@macphisto.homeunix.org...
"M.B." <mbinder@magicnet.com> writes:
"DG" <dany42NOSPAM@free.fr> a écrit dans le message news:
86smmcu8hl.fsf@macphisto.homeunix.org...
"M.B." <mbinder@magicnet.com> writes:
Dans tous les cas, le processeur empile les arguments,
fait au saut a la fonction appelée qui depile, execute,
depile l'adresse de retour et resaute a l'appelant.
C'est là que je suis pas d'accord, selon moi ça se passe plutôt comme
ça dans le cas général :
- Mise des arguments sur la pile _ou_ dans des registres (dépend du
nombre d'argument, de la «pression» sur les registres, du processeur,
du compilo... ) ;
- Saut à la fonction ;
- Création de la frame (sauvegarde du stack pointer (SP); SP <- FP
(frame pointer)) ;
- Récupération des arguments dans la pile _ou_ dans les registres ;
- Exécution du corps de la fonction ;
- Rangement du résultat de la fonction (le cas échéant) dans la pile
ou dans un registre ;
- Remise de la frame dans son état initial ( FP <- SP ; SP <-
savegarde du SP) ;
- Retour à l'adresse de l'appelant + taille de l'exécution d'appel ;
Ben oui, on est d'accord, si tu veux approfondir.
Dans ce cas là tu contredis avec ce que tu disais tout à l'heure à savoir
que les arguments sont _toujours_ passés sur la pile ; donc oui on est
d'accord maintenant :-).
Que ce soit la pile ou un registre specialisé dans un processeur
particulier, ca ne change rien.
Mon propos est de dire qu'il vaut mieux connaitre ces mecanismes,
ca aide a comprendre certains effets pervers de programmes en phase
de debug.
Dans tous les cas, le processeur empile les arguments, fait au saut a la fonction appelée qui depile, execute, depile l'adresse de retour et resaute a l'appelant.
C'est là que je suis pas d'accord, selon moi ça se passe plutôt comme ça dans le cas général :
- Mise des arguments sur la pile _ou_ dans des registres (dépend du nombre d'argument, de la «pression» sur les registres, du processeur, du compilo... ) ; - Saut à la fonction ; - Création de la frame (sauvegarde du stack pointer (SP); SP <- FP (frame pointer)) ; - Récupération des arguments dans la pile _ou_ dans les registres ; - Exécution du corps de la fonction ; - Rangement du résultat de la fonction (le cas échéant) dans la pile ou dans un registre ; - Remise de la frame dans son état initial ( FP <- SP ; SP <- savegarde du SP) ; - Retour à l'adresse de l'appelant + taille de l'exécution d'appel ;
Ben oui, on est d'accord, si tu veux approfondir.
Dans ce cas là tu contredis avec ce que tu disais tout à l'heure à savoir que les arguments sont _toujours_ passés sur la pile ; donc oui on est d'accord maintenant :-).
Que ce soit la pile ou un registre specialisé dans un processeur particulier, ca ne change rien.
Mon propos est de dire qu'il vaut mieux connaitre ces mecanismes, ca aide a comprendre certains effets pervers de programmes en phase de debug.
MB
DG
"M.B." writes: [...]
Que ce soit la pile ou un registre specialisé dans un processeur particulier, ca ne change rien.
Mon propos est de dire qu'il vaut mieux connaitre ces mecanismes, ca aide a comprendre certains effets pervers de programmes en phase de debug.
Et le mien était de dire que ton assertion « Les arguments des fonctions passent TOUJOURS par la pile. Je suis surpris qu'un programmeur C++ ne sache pas ca » est fausse.
"M.B." <mbinder@magicnet.com> writes:
[...]
Que ce soit la pile ou un registre specialisé dans un processeur
particulier, ca ne change rien.
Mon propos est de dire qu'il vaut mieux connaitre ces mecanismes,
ca aide a comprendre certains effets pervers de programmes en phase
de debug.
Et le mien était de dire que ton assertion « Les arguments des
fonctions passent TOUJOURS par la pile. Je suis surpris qu'un
programmeur C++ ne sache pas ca » est fausse.
Que ce soit la pile ou un registre specialisé dans un processeur particulier, ca ne change rien.
Mon propos est de dire qu'il vaut mieux connaitre ces mecanismes, ca aide a comprendre certains effets pervers de programmes en phase de debug.
Et le mien était de dire que ton assertion « Les arguments des fonctions passent TOUJOURS par la pile. Je suis surpris qu'un programmeur C++ ne sache pas ca » est fausse.
M.B.
"Jonathan Mcdougall" a écrit dans le message news: A%Eeb.104899$
Ils passent par ou les arguments?
Ça dépend de ton implémentation. Je me souviens d'un ancien ordinateur où c'était un petit noir qui courait à l'intérieur, mais ça fait bien longtemps, je peux me tromper.
Oui, je me souviens. Il fallait un gros blanc pour le fouetter, pour augmenter la vitesse d'execution du programme.
Une epoque revolue.
;-) MB
"Jonathan Mcdougall" <jonathanmcdougall@DELyahoo.ca> a écrit dans le message
news: A%Eeb.104899$Wk2.1768207@weber.videotron.net...
Ils passent par ou les arguments?
Ça dépend de ton implémentation. Je me souviens d'un ancien ordinateur
où c'était un petit noir qui courait à l'intérieur, mais ça fait bien
longtemps, je peux me tromper.
Oui, je me souviens. Il fallait un gros blanc pour le
fouetter, pour augmenter la vitesse d'execution du
programme.
"Jonathan Mcdougall" a écrit dans le message news: A%Eeb.104899$
Ils passent par ou les arguments?
Ça dépend de ton implémentation. Je me souviens d'un ancien ordinateur où c'était un petit noir qui courait à l'intérieur, mais ça fait bien longtemps, je peux me tromper.
Oui, je me souviens. Il fallait un gros blanc pour le fouetter, pour augmenter la vitesse d'execution du programme.
Une epoque revolue.
;-) MB
M.B.
"DG" a écrit dans le message news:
"M.B." writes: [...]
Que ce soit la pile ou un registre specialisé dans un processeur particulier, ca ne change rien.
Mon propos est de dire qu'il vaut mieux connaitre ces mecanismes, ca aide a comprendre certains effets pervers de programmes en phase de debug.
Et le mien était de dire que ton assertion « Les arguments des fonctions passent TOUJOURS par la pile. Je suis surpris qu'un programmeur C++ ne sache pas ca » est fausse.
Tu joues sur les mots.
MB
"DG" <dany42NOSPAM@free.fr> a écrit dans le message news:
86k77ou7lh.fsf@macphisto.homeunix.org...
"M.B." <mbinder@magicnet.com> writes:
[...]
Que ce soit la pile ou un registre specialisé dans un processeur
particulier, ca ne change rien.
Mon propos est de dire qu'il vaut mieux connaitre ces mecanismes,
ca aide a comprendre certains effets pervers de programmes en phase
de debug.
Et le mien était de dire que ton assertion « Les arguments des
fonctions passent TOUJOURS par la pile. Je suis surpris qu'un
programmeur C++ ne sache pas ca » est fausse.
Que ce soit la pile ou un registre specialisé dans un processeur particulier, ca ne change rien.
Mon propos est de dire qu'il vaut mieux connaitre ces mecanismes, ca aide a comprendre certains effets pervers de programmes en phase de debug.
Et le mien était de dire que ton assertion « Les arguments des fonctions passent TOUJOURS par la pile. Je suis surpris qu'un programmeur C++ ne sache pas ca » est fausse.
Tu joues sur les mots.
MB
Jonathan Mcdougall
Que ce soit la pile ou un registre specialisé dans un processeur particulier, ca ne change rien.
Mon propos est de dire qu'il vaut mieux connaitre ces mecanismes, ca aide a comprendre certains effets pervers de programmes en phase de debug.
Et le mien était de dire que ton assertion « Les arguments des fonctions passent TOUJOURS par la pile. Je suis surpris qu'un programmeur C++ ne sache pas ca » est fausse.
Tu joues sur les mots.
Peut-être, mais sur un mot écris en MAJUSCULE. Disons que ça attire un peu plus l'attention des gens. Surtout quand c'est faux.
Jonathan
Que ce soit la pile ou un registre specialisé dans un processeur
particulier, ca ne change rien.
Mon propos est de dire qu'il vaut mieux connaitre ces mecanismes,
ca aide a comprendre certains effets pervers de programmes en phase
de debug.
Et le mien était de dire que ton assertion « Les arguments des
fonctions passent TOUJOURS par la pile. Je suis surpris qu'un
programmeur C++ ne sache pas ca » est fausse.
Tu joues sur les mots.
Peut-être, mais sur un mot écris en MAJUSCULE. Disons que ça attire
un peu plus l'attention des gens. Surtout quand c'est faux.
Que ce soit la pile ou un registre specialisé dans un processeur particulier, ca ne change rien.
Mon propos est de dire qu'il vaut mieux connaitre ces mecanismes, ca aide a comprendre certains effets pervers de programmes en phase de debug.
Et le mien était de dire que ton assertion « Les arguments des fonctions passent TOUJOURS par la pile. Je suis surpris qu'un programmeur C++ ne sache pas ca » est fausse.
Tu joues sur les mots.
Peut-être, mais sur un mot écris en MAJUSCULE. Disons que ça attire un peu plus l'attention des gens. Surtout quand c'est faux.
