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>
"Jean-Marc Bourguet" a écrit dans le message news:
writes:
Nous sommes entierement d'accord et j'aurais du peut-etre mettre un :-). Je n'enseignerais pas la micro-electronique en prealable a la programmation. Et je doute que MB enseigne l'architecture des processeurs modernes... moi-meme j'ai abandonne de suivre ca en detail alors que le sujet m'interesse.
Je n'ai parlé ni de physique, ni de micro-electronique, ni de processeurs modernes.
La connaissance, meme succinte, de ce qu'est une donnee, une adresse, une instruction, et l'architecture generale d'un ordinateur me parait etre un prerequis indispensable en programmation.
La connaissance du fonctionnement de la pile me parait indispensable pour comprendre les differents types de passage d'arguments.
D'autant que toutes ces notions sont relativement simples a assimiler et a comprendre.
Et il est pour moi evident que mieux on connait le fonctionnement interne d'un ordinateur, mieux on peut le programmer.
MB
"Jean-Marc Bourguet" <jm@bourguet.org> a écrit dans le message news:
pxbznglmmcb.fsf@news.bourguet.org...
kanze@gabi-soft.fr writes:
Nous sommes entierement d'accord et j'aurais du peut-etre mettre
un :-). Je n'enseignerais pas la micro-electronique en prealable a la
programmation. Et je doute que MB enseigne l'architecture des
processeurs modernes... moi-meme j'ai abandonne de suivre ca en detail
alors que le sujet m'interesse.
Je n'ai parlé ni de physique, ni de micro-electronique, ni de processeurs
modernes.
La connaissance, meme succinte, de ce qu'est une donnee, une adresse, une
instruction, et l'architecture generale d'un ordinateur me parait
etre un prerequis indispensable en programmation.
La connaissance du fonctionnement de la pile me parait indispensable pour
comprendre les differents types de passage d'arguments.
D'autant que toutes ces notions sont relativement simples a assimiler et
a comprendre.
Et il est pour moi evident que mieux on connait le fonctionnement interne
d'un ordinateur, mieux on peut le programmer.
"Jean-Marc Bourguet" a écrit dans le message news:
writes:
Nous sommes entierement d'accord et j'aurais du peut-etre mettre un :-). Je n'enseignerais pas la micro-electronique en prealable a la programmation. Et je doute que MB enseigne l'architecture des processeurs modernes... moi-meme j'ai abandonne de suivre ca en detail alors que le sujet m'interesse.
Je n'ai parlé ni de physique, ni de micro-electronique, ni de processeurs modernes.
La connaissance, meme succinte, de ce qu'est une donnee, une adresse, une instruction, et l'architecture generale d'un ordinateur me parait etre un prerequis indispensable en programmation.
La connaissance du fonctionnement de la pile me parait indispensable pour comprendre les differents types de passage d'arguments.
D'autant que toutes ces notions sont relativement simples a assimiler et a comprendre.
Et il est pour moi evident que mieux on connait le fonctionnement interne d'un ordinateur, mieux on peut le programmer.
MB
Jean-Marc Bourguet
"M.B." writes:
"Jean-Marc Bourguet" a écrit dans le message news:
writes:
Nous sommes entierement d'accord et j'aurais du peut-etre mettre un :-). Je n'enseignerais pas la micro-electronique en prealable a la programmation. Et je doute que MB enseigne l'architecture des processeurs modernes... moi-meme j'ai abandonne de suivre ca en detail alors que le sujet m'interesse.
Je n'ai parlé ni de physique, ni de micro-electronique, ni de processeurs modernes.
Ni meme vraissemblablement de processeurs anciens...
La connaissance, meme succinte, de ce qu'est une donnee, une adresse, une instruction, et l'architecture generale d'un ordinateur me parait etre un prerequis indispensable en programmation.
Qu'entends-tu par "architecture generale d'un ordinateur"? J'ai l'impression que tu va me donner une architecture typique des micro des annees 80.
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).
D'autant que toutes ces notions sont relativement simples a assimiler et a comprendre.
Il est possible en effet de presenter une architecture simple possible d'ordinateur. Son utilite pour apprendre a bien programmer me semble douteuse. Elle peut avoir l'effet nocif de laisser penser que la maniere evidente d'implementer quelquechose dessus est la seule possible.
Et il est pour moi evident que mieux on connait le fonctionnement interne d'un ordinateur, mieux on peut le programmer.
C'est bizarre, mais j'ai l'impression que la programmation est un exercice qui consiste a batir des abstractions sur d'autres abstractions. Et quand on programme en C++, les abstractions de plus bas niveaux utilisees sont celles fournies par le langage C++, pas celles de l'architecture ni celles de la micro-architecture.
A penser a trop bas niveau, on fini par croire que faire des soustractions pour mettre en minuscule ou mettre un decalage quand on veut faire une multiplication est savoir bien programmer.
-- Jean-Marc FAQ de fclc++: http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ C++ FAQ Lite en VF: http://www.ifrance.com/jlecomte/c++/c++-faq-lite/index.html Site de usenet-fr: http://www.usenet-fr.news.eu.org
"M.B." <mbinder@magicnet.com> writes:
"Jean-Marc Bourguet" <jm@bourguet.org> a écrit dans le message news:
pxbznglmmcb.fsf@news.bourguet.org...
kanze@gabi-soft.fr writes:
Nous sommes entierement d'accord et j'aurais du peut-etre mettre
un :-). Je n'enseignerais pas la micro-electronique en prealable
a la programmation. Et je doute que MB enseigne l'architecture
des processeurs modernes... moi-meme j'ai abandonne de suivre ca
en detail alors que le sujet m'interesse.
Je n'ai parlé ni de physique, ni de micro-electronique, ni de
processeurs modernes.
Ni meme vraissemblablement de processeurs anciens...
La connaissance, meme succinte, de ce qu'est une donnee, une
adresse, une instruction, et l'architecture generale d'un ordinateur
me parait etre un prerequis indispensable en programmation.
Qu'entends-tu par "architecture generale d'un ordinateur"? J'ai
l'impression que tu va me donner une architecture typique des micro
des annees 80.
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).
D'autant que toutes ces notions sont relativement simples a
assimiler et a comprendre.
Il est possible en effet de presenter une architecture simple possible
d'ordinateur. Son utilite pour apprendre a bien programmer me semble
douteuse. Elle peut avoir l'effet nocif de laisser penser que la
maniere evidente d'implementer quelquechose dessus est la seule
possible.
Et il est pour moi evident que mieux on connait le fonctionnement
interne d'un ordinateur, mieux on peut le programmer.
C'est bizarre, mais j'ai l'impression que la programmation est un
exercice qui consiste a batir des abstractions sur d'autres
abstractions. Et quand on programme en C++, les abstractions de plus
bas niveaux utilisees sont celles fournies par le langage C++, pas
celles de l'architecture ni celles de la micro-architecture.
A penser a trop bas niveau, on fini par croire que faire des
soustractions pour mettre en minuscule ou mettre un decalage quand on
veut faire une multiplication est savoir bien programmer.
--
Jean-Marc
FAQ de fclc++: http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ
C++ FAQ Lite en VF: http://www.ifrance.com/jlecomte/c++/c++-faq-lite/index.html
Site de usenet-fr: http://www.usenet-fr.news.eu.org
"Jean-Marc Bourguet" a écrit dans le message news:
writes:
Nous sommes entierement d'accord et j'aurais du peut-etre mettre un :-). Je n'enseignerais pas la micro-electronique en prealable a la programmation. Et je doute que MB enseigne l'architecture des processeurs modernes... moi-meme j'ai abandonne de suivre ca en detail alors que le sujet m'interesse.
Je n'ai parlé ni de physique, ni de micro-electronique, ni de processeurs modernes.
Ni meme vraissemblablement de processeurs anciens...
La connaissance, meme succinte, de ce qu'est une donnee, une adresse, une instruction, et l'architecture generale d'un ordinateur me parait etre un prerequis indispensable en programmation.
Qu'entends-tu par "architecture generale d'un ordinateur"? J'ai l'impression que tu va me donner une architecture typique des micro des annees 80.
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).
D'autant que toutes ces notions sont relativement simples a assimiler et a comprendre.
Il est possible en effet de presenter une architecture simple possible d'ordinateur. Son utilite pour apprendre a bien programmer me semble douteuse. Elle peut avoir l'effet nocif de laisser penser que la maniere evidente d'implementer quelquechose dessus est la seule possible.
Et il est pour moi evident que mieux on connait le fonctionnement interne d'un ordinateur, mieux on peut le programmer.
C'est bizarre, mais j'ai l'impression que la programmation est un exercice qui consiste a batir des abstractions sur d'autres abstractions. Et quand on programme en C++, les abstractions de plus bas niveaux utilisees sont celles fournies par le langage C++, pas celles de l'architecture ni celles de la micro-architecture.
A penser a trop bas niveau, on fini par croire que faire des soustractions pour mettre en minuscule ou mettre un decalage quand on veut faire une multiplication est savoir bien programmer.
-- Jean-Marc FAQ de fclc++: http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ C++ FAQ Lite en VF: http://www.ifrance.com/jlecomte/c++/c++-faq-lite/index.html Site de usenet-fr: http://www.usenet-fr.news.eu.org
M.B.
"Jean-Marc Bourguet" a écrit dans le message news:
"M.B." writes:
Qu'entends-tu par "architecture generale d'un ordinateur"? J'ai l'impression que tu va me donner une architecture typique des micro des annees 80.
L'architecture date de 1946, d'un certain Mr Von Neumann. Rien de fondamentalement neuf depuis.
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. Je suis surpris qu'un programmeur C++ ne sache pas ca.
D'autant que toutes ces notions sont relativement simples a assimiler et a comprendre.
Il est possible en effet de presenter une architecture simple possible d'ordinateur. Son utilite pour apprendre a bien programmer me semble douteuse. Elle peut avoir l'effet nocif de laisser penser que la maniere evidente d'implementer quelquechose dessus est la seule possible.
Et il est pour moi evident que mieux on connait le fonctionnement interne d'un ordinateur, mieux on peut le programmer.
C'est bizarre, mais j'ai l'impression que la programmation est un exercice qui consiste a batir des abstractions sur d'autres abstractions. Et quand on programme en C++, les abstractions de plus bas niveaux utilisees sont celles fournies par le langage C++, pas celles de l'architecture ni celles de la micro-architecture.
Le B-A-BA du fonctionnement d'un ordinateur n'a rien d'abstrait. On ne peut pas trouver plus concret.
A penser a trop bas niveau, on fini par croire que faire des soustractions pour mettre en minuscule ou mettre un decalage quand on veut faire une multiplication est savoir bien programmer.
Oui mettre un decalage pour multiplier par une puissance de 2, c'est savoir programmer avec la connaissance de la machine qu'on programme. ET cela manque a bien des programmeurs.
MB
"Jean-Marc Bourguet" <jm@bourguet.org> a écrit dans le message news:
pxboex0apg4.fsf@news.bourguet.org...
"M.B." <mbinder@magicnet.com> writes:
Qu'entends-tu par "architecture generale d'un ordinateur"? J'ai
l'impression que tu va me donner une architecture typique des micro
des annees 80.
L'architecture date de 1946, d'un certain Mr Von Neumann.
Rien de fondamentalement neuf depuis.
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.
Je suis surpris qu'un programmeur C++ ne sache pas ca.
D'autant que toutes ces notions sont relativement simples a
assimiler et a comprendre.
Il est possible en effet de presenter une architecture simple possible
d'ordinateur. Son utilite pour apprendre a bien programmer me semble
douteuse. Elle peut avoir l'effet nocif de laisser penser que la
maniere evidente d'implementer quelquechose dessus est la seule
possible.
Et il est pour moi evident que mieux on connait le fonctionnement
interne d'un ordinateur, mieux on peut le programmer.
C'est bizarre, mais j'ai l'impression que la programmation est un
exercice qui consiste a batir des abstractions sur d'autres
abstractions. Et quand on programme en C++, les abstractions de plus
bas niveaux utilisees sont celles fournies par le langage C++, pas
celles de l'architecture ni celles de la micro-architecture.
Le B-A-BA du fonctionnement d'un ordinateur n'a rien d'abstrait.
On ne peut pas trouver plus concret.
A penser a trop bas niveau, on fini par croire que faire des
soustractions pour mettre en minuscule ou mettre un decalage quand on
veut faire une multiplication est savoir bien programmer.
Oui mettre un decalage pour multiplier par une puissance de 2, c'est
savoir programmer avec la connaissance de la machine qu'on programme.
ET cela manque a bien des programmeurs.
"Jean-Marc Bourguet" a écrit dans le message news:
"M.B." writes:
Qu'entends-tu par "architecture generale d'un ordinateur"? J'ai l'impression que tu va me donner une architecture typique des micro des annees 80.
L'architecture date de 1946, d'un certain Mr Von Neumann. Rien de fondamentalement neuf depuis.
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. Je suis surpris qu'un programmeur C++ ne sache pas ca.
D'autant que toutes ces notions sont relativement simples a assimiler et a comprendre.
Il est possible en effet de presenter une architecture simple possible d'ordinateur. Son utilite pour apprendre a bien programmer me semble douteuse. Elle peut avoir l'effet nocif de laisser penser que la maniere evidente d'implementer quelquechose dessus est la seule possible.
Et il est pour moi evident que mieux on connait le fonctionnement interne d'un ordinateur, mieux on peut le programmer.
C'est bizarre, mais j'ai l'impression que la programmation est un exercice qui consiste a batir des abstractions sur d'autres abstractions. Et quand on programme en C++, les abstractions de plus bas niveaux utilisees sont celles fournies par le langage C++, pas celles de l'architecture ni celles de la micro-architecture.
Le B-A-BA du fonctionnement d'un ordinateur n'a rien d'abstrait. On ne peut pas trouver plus concret.
A penser a trop bas niveau, on fini par croire que faire des soustractions pour mettre en minuscule ou mettre un decalage quand on veut faire une multiplication est savoir bien programmer.
Oui mettre un decalage pour multiplier par une puissance de 2, c'est savoir programmer avec la connaissance de la machine qu'on programme. ET cela manque a bien des programmeurs.
MB
DG
"M.B." writes: [...]
Les arguments des fonctions passent TOUJOURS par la pile. Je suis surpris qu'un programmeur C++ ne sache pas ca.
Hum, je me permet d'avoir de sérieux doutes sur ce point. Pourrai-je connaitre quelles sont tes sources (est-ce la norme qui l'impose) ?
Pour ma part, je crois que cela dépend plutôt de ton processeur et de ton compilateur... Par exemple sur MIPS il y a 4 registres qui sont dédiés aux arguments de fonctions (certes après on est libre de les utiliser comme tel ou pas...). En fait je vois un seul cas où il est réellement nécessaire d'avoir les arguments sur la pile : c'est dans le cas des fonctions ayant un nombre d'argument variable (stdarg).
"M.B." <mbinder@magicnet.com> writes:
[...]
Les arguments des fonctions passent TOUJOURS par la pile.
Je suis surpris qu'un programmeur C++ ne sache pas ca.
Hum, je me permet d'avoir de sérieux doutes sur ce point. Pourrai-je
connaitre quelles sont tes sources (est-ce la norme qui l'impose) ?
Pour ma part, je crois que cela dépend plutôt de ton processeur et de
ton compilateur... Par exemple sur MIPS il y a 4 registres qui sont
dédiés aux arguments de fonctions (certes après on est libre de les
utiliser comme tel ou pas...). En fait je vois un seul cas où il est
réellement nécessaire d'avoir les arguments sur la pile : c'est dans
le cas des fonctions ayant un nombre d'argument variable (stdarg).
Les arguments des fonctions passent TOUJOURS par la pile. Je suis surpris qu'un programmeur C++ ne sache pas ca.
Hum, je me permet d'avoir de sérieux doutes sur ce point. Pourrai-je connaitre quelles sont tes sources (est-ce la norme qui l'impose) ?
Pour ma part, je crois que cela dépend plutôt de ton processeur et de ton compilateur... Par exemple sur MIPS il y a 4 registres qui sont dédiés aux arguments de fonctions (certes après on est libre de les utiliser comme tel ou pas...). En fait je vois un seul cas où il est réellement nécessaire d'avoir les arguments sur la pile : c'est dans le cas des fonctions ayant un nombre d'argument variable (stdarg).
Falk Tannhäuser
Les arguments des fonctions passent TOUJOURS par la pile. ou dans des registres, ou bien la fonction est "inlinée" et
optimisée ...
A penser a trop bas niveau, on fini par croire que faire des soustractions pour mettre en minuscule ou mettre un decalage quand on veut faire une multiplication est savoir bien programmer. Oui mettre un decalage pour multiplier par une puissance de 2, c'est
savoir programmer avec la connaissance de la machine qu'on programme. ou manquer de la connaissance des capacités d'optimisation d'un
compilateur moderne qui fait très bien ce genre de choses ...
ET cela manque a bien des programmeurs. Je suis d'accord qu'il est bien de savoir, par exemple, comment
une machine représente les entiers en binaire, mais pour bien de domaines d'application, ce savoir ne me semble pas indispensable. Il s'agit de savoir se placer sur le niveau d'abstraction approprié, qui n'est pas le même si on écrit un driver pour un composant réseau (gestion des registres, de la DMA, des interruptions ...) que dans le cas d'une application qui traite des ordres d'achat / vente à la bourse...
Falk
Les arguments des fonctions passent TOUJOURS par la pile.
ou dans des registres, ou bien la fonction est "inlinée" et
optimisée ...
A penser a trop bas niveau, on fini par croire que faire des
soustractions pour mettre en minuscule ou mettre un decalage quand on
veut faire une multiplication est savoir bien programmer.
Oui mettre un decalage pour multiplier par une puissance de 2, c'est
savoir programmer avec la connaissance de la machine qu'on programme.
ou manquer de la connaissance des capacités d'optimisation d'un
compilateur moderne qui fait très bien ce genre de choses ...
ET cela manque a bien des programmeurs.
Je suis d'accord qu'il est bien de savoir, par exemple, comment
une machine représente les entiers en binaire, mais pour bien de
domaines d'application, ce savoir ne me semble pas indispensable.
Il s'agit de savoir se placer sur le niveau d'abstraction approprié,
qui n'est pas le même si on écrit un driver pour un composant réseau
(gestion des registres, de la DMA, des interruptions ...) que dans
le cas d'une application qui traite des ordres d'achat / vente à
la bourse...
Les arguments des fonctions passent TOUJOURS par la pile. ou dans des registres, ou bien la fonction est "inlinée" et
optimisée ...
A penser a trop bas niveau, on fini par croire que faire des soustractions pour mettre en minuscule ou mettre un decalage quand on veut faire une multiplication est savoir bien programmer. Oui mettre un decalage pour multiplier par une puissance de 2, c'est
savoir programmer avec la connaissance de la machine qu'on programme. ou manquer de la connaissance des capacités d'optimisation d'un
compilateur moderne qui fait très bien ce genre de choses ...
ET cela manque a bien des programmeurs. Je suis d'accord qu'il est bien de savoir, par exemple, comment
une machine représente les entiers en binaire, mais pour bien de domaines d'application, ce savoir ne me semble pas indispensable. Il s'agit de savoir se placer sur le niveau d'abstraction approprié, qui n'est pas le même si on écrit un driver pour un composant réseau (gestion des registres, de la DMA, des interruptions ...) que dans le cas d'une application qui traite des ordres d'achat / vente à la bourse...
Falk
M.B.
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.
Voir un cours d'electronique numerique de niveau DUT ou maitrise. Ou les bases de l'Assembleur.
MB
"DG" a écrit dans le message news:
"M.B." writes: [...]
Les arguments des fonctions passent TOUJOURS par la pile. Je suis surpris qu'un programmeur C++ ne sache pas ca.
Hum, je me permet d'avoir de sérieux doutes sur ce point. Pourrai-je connaitre quelles sont tes sources (est-ce la norme qui l'impose) ?
Pour ma part, je crois que cela dépend plutôt de ton processeur et de ton compilateur... Par exemple sur MIPS il y a 4 registres qui sont dédiés aux arguments de fonctions (certes après on est libre de les utiliser comme tel ou pas...). En fait je vois un seul cas où il est réellement nécessaire d'avoir les arguments sur la pile : c'est dans le cas des fonctions ayant un nombre d'argument variable (stdarg).
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.
Voir un cours d'electronique numerique de niveau DUT ou
maitrise. Ou les bases de l'Assembleur.
MB
"DG" <dany42NOSPAM@free.fr> a écrit dans le message news:
86zngkua3w.fsf@macphisto.homeunix.org...
"M.B." <mbinder@magicnet.com> writes:
[...]
Les arguments des fonctions passent TOUJOURS par la pile.
Je suis surpris qu'un programmeur C++ ne sache pas ca.
Hum, je me permet d'avoir de sérieux doutes sur ce point. Pourrai-je
connaitre quelles sont tes sources (est-ce la norme qui l'impose) ?
Pour ma part, je crois que cela dépend plutôt de ton processeur et de
ton compilateur... Par exemple sur MIPS il y a 4 registres qui sont
dédiés aux arguments de fonctions (certes après on est libre de les
utiliser comme tel ou pas...). En fait je vois un seul cas où il est
réellement nécessaire d'avoir les arguments sur la pile : c'est dans
le cas des fonctions ayant un nombre d'argument variable (stdarg).
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.
Voir un cours d'electronique numerique de niveau DUT ou maitrise. Ou les bases de l'Assembleur.
MB
"DG" a écrit dans le message news:
"M.B." writes: [...]
Les arguments des fonctions passent TOUJOURS par la pile. Je suis surpris qu'un programmeur C++ ne sache pas ca.
Hum, je me permet d'avoir de sérieux doutes sur ce point. Pourrai-je connaitre quelles sont tes sources (est-ce la norme qui l'impose) ?
Pour ma part, je crois que cela dépend plutôt de ton processeur et de ton compilateur... Par exemple sur MIPS il y a 4 registres qui sont dédiés aux arguments de fonctions (certes après on est libre de les utiliser comme tel ou pas...). En fait je vois un seul cas où il est réellement nécessaire d'avoir les arguments sur la pile : c'est dans le cas des fonctions ayant un nombre d'argument variable (stdarg).
Jonathan Mcdougall
A penser a trop bas niveau, on fini par croire que faire des
soustractions pour mettre en minuscule ou mettre un decalage quand on veut faire une multiplication est savoir bien programmer.
Oui mettre un decalage pour multiplier par une puissance de 2, c'est savoir programmer avec la connaissance de la machine qu'on programme. ET cela manque a bien des programmeurs.
Connaitre la machine a ajourd'hui (et heureusement) beaucoup moins d'importance qu'avant. Le décalage est d'après moi un très mauvais exemple de "savoir programmer avec la connaissance de la machine qu'on programme". Et je n'arrive pas à en trouver de bons.
Jonathan
A penser a trop bas niveau, on fini par croire que faire des
soustractions pour mettre en minuscule ou mettre un decalage quand on
veut faire une multiplication est savoir bien programmer.
Oui mettre un decalage pour multiplier par une puissance de 2, c'est
savoir programmer avec la connaissance de la machine qu'on programme.
ET cela manque a bien des programmeurs.
Connaitre la machine a ajourd'hui (et heureusement) beaucoup moins
d'importance qu'avant. Le décalage est d'après moi un très mauvais
exemple de "savoir programmer avec la connaissance de la machine
qu'on programme". Et je n'arrive pas à en trouver de bons.
A penser a trop bas niveau, on fini par croire que faire des
soustractions pour mettre en minuscule ou mettre un decalage quand on veut faire une multiplication est savoir bien programmer.
Oui mettre un decalage pour multiplier par une puissance de 2, c'est savoir programmer avec la connaissance de la machine qu'on programme. ET cela manque a bien des programmeurs.
Connaitre la machine a ajourd'hui (et heureusement) beaucoup moins d'importance qu'avant. Le décalage est d'après moi un très mauvais exemple de "savoir programmer avec la connaissance de la machine qu'on programme". Et je n'arrive pas à en trouver de bons.
Jonathan
M.B.
"Jonathan Mcdougall" a écrit dans le message news: IxEeb.104890$
Connaitre la machine a ajourd'hui (et heureusement) beaucoup moins d'importance qu'avant. Le décalage est d'après moi un très mauvais exemple de "savoir programmer avec la connaissance de la machine qu'on programme". Et je n'arrive pas à en trouver de bons.
Et quand tu as un bug 'Stack Overflow', tu fais quoi si tu ne sais pas ce qu'est une 'stack' ?
Et tu expliques comment a des etudiants que le passage d'argument par adresse ou par valeur ?
MB
"Jonathan Mcdougall" <jonathanmcdougall@DELyahoo.ca> a écrit dans le message
news: IxEeb.104890$Wk2.1761191@weber.videotron.net...
Connaitre la machine a ajourd'hui (et heureusement) beaucoup moins
d'importance qu'avant. Le décalage est d'après moi un très mauvais
exemple de "savoir programmer avec la connaissance de la machine
qu'on programme". Et je n'arrive pas à en trouver de bons.
Et quand tu as un bug 'Stack Overflow', tu fais quoi si tu
ne sais pas ce qu'est une 'stack' ?
Et tu expliques comment a des etudiants que le passage d'argument
par adresse ou par valeur ?
"Jonathan Mcdougall" a écrit dans le message news: IxEeb.104890$
Connaitre la machine a ajourd'hui (et heureusement) beaucoup moins d'importance qu'avant. Le décalage est d'après moi un très mauvais exemple de "savoir programmer avec la connaissance de la machine qu'on programme". Et je n'arrive pas à en trouver de bons.
Et quand tu as un bug 'Stack Overflow', tu fais quoi si tu ne sais pas ce qu'est une 'stack' ?
Et tu expliques comment a des etudiants que le passage d'argument par adresse ou par valeur ?
MB
Jonathan Mcdougall
Connaitre la machine a ajourd'hui (et heureusement) beaucoup moins d'importance qu'avant. Le décalage est d'après moi un très mauvais exemple de "savoir programmer avec la connaissance de la machine qu'on programme". Et je n'arrive pas à en trouver de bons.
Et quand tu as un bug 'Stack Overflow', tu fais quoi si tu ne sais pas ce qu'est une 'stack' ?
Et tu expliques comment a des etudiants que le passage d'argument par adresse ou par valeur ?
Je n'ai pas dis que l'on n'avait pas besoin de connaitre la machine du tout, j'ai seulement dis que c'était moins beaucoup important qu'avant.
Jonathan
Connaitre la machine a ajourd'hui (et heureusement) beaucoup moins
d'importance qu'avant. Le décalage est d'après moi un très mauvais
exemple de "savoir programmer avec la connaissance de la machine
qu'on programme". Et je n'arrive pas à en trouver de bons.
Et quand tu as un bug 'Stack Overflow', tu fais quoi si tu
ne sais pas ce qu'est une 'stack' ?
Et tu expliques comment a des etudiants que le passage d'argument
par adresse ou par valeur ?
Je n'ai pas dis que l'on n'avait pas besoin de connaitre la machine
du tout, j'ai seulement dis que c'était moins beaucoup important
qu'avant.
Connaitre la machine a ajourd'hui (et heureusement) beaucoup moins d'importance qu'avant. Le décalage est d'après moi un très mauvais exemple de "savoir programmer avec la connaissance de la machine qu'on programme". Et je n'arrive pas à en trouver de bons.
Et quand tu as un bug 'Stack Overflow', tu fais quoi si tu ne sais pas ce qu'est une 'stack' ?
Et tu expliques comment a des etudiants que le passage d'argument par adresse ou par valeur ?
Je n'ai pas dis que l'on n'avait pas besoin de connaitre la machine du tout, j'ai seulement dis que c'était moins beaucoup important qu'avant.
Jonathan
Gabriel Dos Reis
"M.B." 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é.
-- Gaby
"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é.
| > > 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é.
