a écrit :
>> void f(int n)
>> {
>> if (n > 0)
>> {
>> f(n - 1);
>> printf("%d ", (n - 1) * (n - 1));
>> }
>> }
> Qu'est-ce qui se produit après "f(n-1)" ?La séquence "rembobine"???
Oui
> càd après void f(10) ;
Euh non, void f(10) ne veut rien dire.
Bon pour simplifier les explications, supposons que le code soit
#include <stdio.h>
void f(int n)
{
if (n > 0)
{
f(n-1)
printf("%d ", (n - 1) * (n - 1));
}
}
int main(void)
{
f(3);
printf("n");
return 0;
}
et qui affiche :
0 1 4
Au premier appel f(3), immédiatement f est relancée par l'appel f(2) qui
lui même est relancé par f(1) qui à nouveau appelle f(0). C'est
l'empilement des appels. Donc pour chacun de ces appels, l'exécution de
la fonction f s'est arrêté à la ligne suivante :
f(n - 1);
Maintenant, à cause de la ligne
if (n > 0)
f(0) se termine dans rien faire et c'est là que vient le point capital :
on revient à la fonction appelante (/return to the caller/) qui était f
bien sûr avec le paramètre n=1. Donc le programme continue après la ligne
f(n - 1);
et donc avec l'instruction
printf("%d ", (n - 1) * (n - 1));
où n=1 ce qui affiche 0. Vu le code de f, l'exécution de f(1) se te rmine
et comme f(1) avait été appelé par f(2), on continue le programme l à où
il était resté, le printf est exécuté. Bon, et ainsi de suite jus qu'au
premier appel (n=3) et qui va afficher 4 puis se terminer. La fonction
qui avait appelée f(3) est main() donc on revient à main, ce qui clot le
programme.
Le fait que la fonction soit récursive ne change en fait
fondamentalement rien à la façon dont les appels sont effectués et achevés.
> void f(9) au second appel )à cause de f
> (n-1), ...void f(8) ... où printf est inclus avant que la séquen ce
> rembobine dans ce cas, 81 64 42 ...devrait être affichés ?
Non, justement. Modifie le code en plaçant le f(n-1) après le printf( )
et tu verras ce qu'il se passe.
bpascal...@googlemail.com a écrit :
>> void f(int n)
>> {
>> if (n > 0)
>> {
>> f(n - 1);
>> printf("%d ", (n - 1) * (n - 1));
>> }
>> }
> Qu'est-ce qui se produit après "f(n-1)" ?La séquence "rembobine"???
Oui
> càd après void f(10) ;
Euh non, void f(10) ne veut rien dire.
Bon pour simplifier les explications, supposons que le code soit
#include <stdio.h>
void f(int n)
{
if (n > 0)
{
f(n-1)
printf("%d ", (n - 1) * (n - 1));
}
}
int main(void)
{
f(3);
printf("n");
return 0;
}
et qui affiche :
0 1 4
Au premier appel f(3), immédiatement f est relancée par l'appel f(2) qui
lui même est relancé par f(1) qui à nouveau appelle f(0). C'est
l'empilement des appels. Donc pour chacun de ces appels, l'exécution de
la fonction f s'est arrêté à la ligne suivante :
f(n - 1);
Maintenant, à cause de la ligne
if (n > 0)
f(0) se termine dans rien faire et c'est là que vient le point capital :
on revient à la fonction appelante (/return to the caller/) qui était f
bien sûr avec le paramètre n=1. Donc le programme continue après la ligne
f(n - 1);
et donc avec l'instruction
printf("%d ", (n - 1) * (n - 1));
où n=1 ce qui affiche 0. Vu le code de f, l'exécution de f(1) se te rmine
et comme f(1) avait été appelé par f(2), on continue le programme l à où
il était resté, le printf est exécuté. Bon, et ainsi de suite jus qu'au
premier appel (n=3) et qui va afficher 4 puis se terminer. La fonction
qui avait appelée f(3) est main() donc on revient à main, ce qui clot le
programme.
Le fait que la fonction soit récursive ne change en fait
fondamentalement rien à la façon dont les appels sont effectués et achevés.
> void f(9) au second appel )à cause de f
> (n-1), ...void f(8) ... où printf est inclus avant que la séquen ce
> rembobine dans ce cas, 81 64 42 ...devrait être affichés ?
Non, justement. Modifie le code en plaçant le f(n-1) après le printf( )
et tu verras ce qu'il se passe.
a écrit :
>> void f(int n)
>> {
>> if (n > 0)
>> {
>> f(n - 1);
>> printf("%d ", (n - 1) * (n - 1));
>> }
>> }
> Qu'est-ce qui se produit après "f(n-1)" ?La séquence "rembobine"???
Oui
> càd après void f(10) ;
Euh non, void f(10) ne veut rien dire.
Bon pour simplifier les explications, supposons que le code soit
#include <stdio.h>
void f(int n)
{
if (n > 0)
{
f(n-1)
printf("%d ", (n - 1) * (n - 1));
}
}
int main(void)
{
f(3);
printf("n");
return 0;
}
et qui affiche :
0 1 4
Au premier appel f(3), immédiatement f est relancée par l'appel f(2) qui
lui même est relancé par f(1) qui à nouveau appelle f(0). C'est
l'empilement des appels. Donc pour chacun de ces appels, l'exécution de
la fonction f s'est arrêté à la ligne suivante :
f(n - 1);
Maintenant, à cause de la ligne
if (n > 0)
f(0) se termine dans rien faire et c'est là que vient le point capital :
on revient à la fonction appelante (/return to the caller/) qui était f
bien sûr avec le paramètre n=1. Donc le programme continue après la ligne
f(n - 1);
et donc avec l'instruction
printf("%d ", (n - 1) * (n - 1));
où n=1 ce qui affiche 0. Vu le code de f, l'exécution de f(1) se te rmine
et comme f(1) avait été appelé par f(2), on continue le programme l à où
il était resté, le printf est exécuté. Bon, et ainsi de suite jus qu'au
premier appel (n=3) et qui va afficher 4 puis se terminer. La fonction
qui avait appelée f(3) est main() donc on revient à main, ce qui clot le
programme.
Le fait que la fonction soit récursive ne change en fait
fondamentalement rien à la façon dont les appels sont effectués et achevés.
> void f(9) au second appel )à cause de f
> (n-1), ...void f(8) ... où printf est inclus avant que la séquen ce
> rembobine dans ce cas, 81 64 42 ...devrait être affichés ?
Non, justement. Modifie le code en plaçant le f(n-1) après le printf( )
et tu verras ce qu'il se passe.
Wykaaa a écrit :Alors je comprends que tu n'aime pas la récursivité.
Au contraire, j'adore pratiquer la récursivité et je peux passer des
heures à épurer un code récursif.
Je ne vois pas ce qui te laisse dire ça. Tout ce dont tu as parlé
précédemment n'a rien à voir avec le C me semble-t-il et je ne vois pas
en quoi ça m'aiderait à mieux coder en C.
Oui la suite de Fibonacci écrite de cette manière n'est pas optimisée
car les mêmes évaluations se font à plusieurs endroits.ce qui une fois de plus montre qu'il y a une distance entre le concept
souvent simple voire trivial, et l'implémentation. Bref, ne confondons
pas récursivité de salon et récursivité de codeur.
Ce n'est pas à moi que tu vas tenir ce discours. J'ai trempé pendant 10
ans dans les compilateurs et il y avait de la récursion à tous les
étages...
La question n'était pas là, tu m'as dit qu'un algorithme récursif devait
suivre "au plus près" la définition mathématique. Mon exemple ci-dessus
prouve le contraire et d'autres exemples pourraient montrer que la
récursivité est plus compliquée à comprendre que ce que dit Richard
Delorme.
Wykaaa a écrit :
Alors je comprends que tu n'aime pas la récursivité.
Au contraire, j'adore pratiquer la récursivité et je peux passer des
heures à épurer un code récursif.
Je ne vois pas ce qui te laisse dire ça. Tout ce dont tu as parlé
précédemment n'a rien à voir avec le C me semble-t-il et je ne vois pas
en quoi ça m'aiderait à mieux coder en C.
Oui la suite de Fibonacci écrite de cette manière n'est pas optimisée
car les mêmes évaluations se font à plusieurs endroits.
ce qui une fois de plus montre qu'il y a une distance entre le concept
souvent simple voire trivial, et l'implémentation. Bref, ne confondons
pas récursivité de salon et récursivité de codeur.
Ce n'est pas à moi que tu vas tenir ce discours. J'ai trempé pendant 10
ans dans les compilateurs et il y avait de la récursion à tous les
étages...
La question n'était pas là, tu m'as dit qu'un algorithme récursif devait
suivre "au plus près" la définition mathématique. Mon exemple ci-dessus
prouve le contraire et d'autres exemples pourraient montrer que la
récursivité est plus compliquée à comprendre que ce que dit Richard
Delorme.
Wykaaa a écrit :Alors je comprends que tu n'aime pas la récursivité.
Au contraire, j'adore pratiquer la récursivité et je peux passer des
heures à épurer un code récursif.
Je ne vois pas ce qui te laisse dire ça. Tout ce dont tu as parlé
précédemment n'a rien à voir avec le C me semble-t-il et je ne vois pas
en quoi ça m'aiderait à mieux coder en C.
Oui la suite de Fibonacci écrite de cette manière n'est pas optimisée
car les mêmes évaluations se font à plusieurs endroits.ce qui une fois de plus montre qu'il y a une distance entre le concept
souvent simple voire trivial, et l'implémentation. Bref, ne confondons
pas récursivité de salon et récursivité de codeur.
Ce n'est pas à moi que tu vas tenir ce discours. J'ai trempé pendant 10
ans dans les compilateurs et il y avait de la récursion à tous les
étages...
La question n'était pas là, tu m'as dit qu'un algorithme récursif devait
suivre "au plus près" la définition mathématique. Mon exemple ci-dessus
prouve le contraire et d'autres exemples pourraient montrer que la
récursivité est plus compliquée à comprendre que ce que dit Richard
Delorme.
> Au premier appel f(3), immédiatement f est relancée par l'appel f(2) qui
lui même est relancé par f(1) qui à nouveau appelle f(0). C'est
l'empilement des appels. Donc pour chacun de ces appels, l'exécution de
la fonction f s'est arrêté à la ligne suivante :
> Au premier appel f(3), immédiatement f est relancée par l'appel f(2) qui
lui même est relancé par f(1) qui à nouveau appelle f(0). C'est
l'empilement des appels. Donc pour chacun de ces appels, l'exécution de
la fonction f s'est arrêté à la ligne suivante :
> Au premier appel f(3), immédiatement f est relancée par l'appel f(2) qui
lui même est relancé par f(1) qui à nouveau appelle f(0). C'est
l'empilement des appels. Donc pour chacun de ces appels, l'exécution de
la fonction f s'est arrêté à la ligne suivante :
Au premier appel f(3), immédiatement f est relancée par l'appel f(2) qui
lui même est relancé par f(1) qui à nouveau appelle f(0). C'est
l'empilement des appels. Donc pour chacun de ces appels, l'exécution de
la fonction f s'est arrêté à la ligne suivante :
Bonjour,
J'ai pu comprendre le concept de récursivité avec votre explication.
Je comprends également que pour comprendre des récursions plus
"sophistiquées", une compréhension de ce qui se passe en compilation/
assembleur est nécessaire. Je pense à l'accès des données en mémoire.
Je ne suis pas encore là, je souhaiterais sortir de ce livre sur
l'architecture des ordinateurs pour passer à la pratique mais si je
vais trop vite, je pense que je devrais retourner à ce livre (et
puisl'inconvénient d'etre autodidacte; il y a aussi le manque de
motivation). Mais selon ce qui est dit dans cette discussion,
comprendre la récursivité permet de comprendre for et while ...
Ce livre n'est pas à coté maintenant mais j'ai en mémoire d'un
pointeur IP ou quelque chose comme ca qui "empile" le résultat des
fonctions dans le stack ou heap je crois et retourne à l'adresse d'une
données dans un buffer selon les instructions du séquenceur ou de
l'unité de commande...
Je pensais que IP n'était employé que pour les fonctions vers les
pointeurs. Et c'est pourquoi je n'ai pas fait le lien en
premier'depuis le début de cette discussion et votre réponse) avec les
fonctions de récursivité qui ne sont pas des fonctions vers les
pointeurs.
Peut-être c'est un autre sujet, mais une fonction vers un pointeur
pourrait rendre l'appel d'une fonction récursive plus rapide?
Merci,
Pascal
Au premier appel f(3), immédiatement f est relancée par l'appel f(2) qui
lui même est relancé par f(1) qui à nouveau appelle f(0). C'est
l'empilement des appels. Donc pour chacun de ces appels, l'exécution de
la fonction f s'est arrêté à la ligne suivante :
Bonjour,
J'ai pu comprendre le concept de récursivité avec votre explication.
Je comprends également que pour comprendre des récursions plus
"sophistiquées", une compréhension de ce qui se passe en compilation/
assembleur est nécessaire. Je pense à l'accès des données en mémoire.
Je ne suis pas encore là, je souhaiterais sortir de ce livre sur
l'architecture des ordinateurs pour passer à la pratique mais si je
vais trop vite, je pense que je devrais retourner à ce livre (et
puisl'inconvénient d'etre autodidacte; il y a aussi le manque de
motivation). Mais selon ce qui est dit dans cette discussion,
comprendre la récursivité permet de comprendre for et while ...
Ce livre n'est pas à coté maintenant mais j'ai en mémoire d'un
pointeur IP ou quelque chose comme ca qui "empile" le résultat des
fonctions dans le stack ou heap je crois et retourne à l'adresse d'une
données dans un buffer selon les instructions du séquenceur ou de
l'unité de commande...
Je pensais que IP n'était employé que pour les fonctions vers les
pointeurs. Et c'est pourquoi je n'ai pas fait le lien en
premier'depuis le début de cette discussion et votre réponse) avec les
fonctions de récursivité qui ne sont pas des fonctions vers les
pointeurs.
Peut-être c'est un autre sujet, mais une fonction vers un pointeur
pourrait rendre l'appel d'une fonction récursive plus rapide?
Merci,
Pascal
Au premier appel f(3), immédiatement f est relancée par l'appel f(2) qui
lui même est relancé par f(1) qui à nouveau appelle f(0). C'est
l'empilement des appels. Donc pour chacun de ces appels, l'exécution de
la fonction f s'est arrêté à la ligne suivante :
Bonjour,
J'ai pu comprendre le concept de récursivité avec votre explication.
Je comprends également que pour comprendre des récursions plus
"sophistiquées", une compréhension de ce qui se passe en compilation/
assembleur est nécessaire. Je pense à l'accès des données en mémoire.
Je ne suis pas encore là, je souhaiterais sortir de ce livre sur
l'architecture des ordinateurs pour passer à la pratique mais si je
vais trop vite, je pense que je devrais retourner à ce livre (et
puisl'inconvénient d'etre autodidacte; il y a aussi le manque de
motivation). Mais selon ce qui est dit dans cette discussion,
comprendre la récursivité permet de comprendre for et while ...
Ce livre n'est pas à coté maintenant mais j'ai en mémoire d'un
pointeur IP ou quelque chose comme ca qui "empile" le résultat des
fonctions dans le stack ou heap je crois et retourne à l'adresse d'une
données dans un buffer selon les instructions du séquenceur ou de
l'unité de commande...
Je pensais que IP n'était employé que pour les fonctions vers les
pointeurs. Et c'est pourquoi je n'ai pas fait le lien en
premier'depuis le début de cette discussion et votre réponse) avec les
fonctions de récursivité qui ne sont pas des fonctions vers les
pointeurs.
Peut-être c'est un autre sujet, mais une fonction vers un pointeur
pourrait rendre l'appel d'une fonction récursive plus rapide?
Merci,
Pascal
Au premier appel f(3), immédiatement f est relancée par l'appel f(2) qui
lui même est relancé par f(1) qui à nouveau appelle f(0). C'est
l'empilement des appels. Donc pour chacun de ces appels, l'exécution de
la fonction f s'est arrêté à la ligne suivante :
Bonjour,
J'ai pu comprendre le concept de récursivité avec votre explication.
Je comprends également que pour comprendre des récursions plus
"sophistiquées", une compréhension de ce qui se passe en compilation/
assembleur est nécessaire. Je pense à l'accès des données en mémoire.
Je ne suis pas encore là, je souhaiterais sortir de ce livre sur
l'architecture des ordinateurs pour passer à la pratique mais si je
vais trop vite, je pense que je devrais retourner à ce livre (et
puisl'inconvénient d'etre autodidacte; il y a aussi le manque de
motivation). Mais selon ce qui est dit dans cette discussion,
comprendre la récursivité permet de comprendre for et while ...
Ce livre n'est pas à coté maintenant mais j'ai en mémoire d'un
pointeur IP ou quelque chose comme ca qui "empile" le résultat des
fonctions dans le stack ou heap je crois et retourne à l'adresse d'une
données dans un buffer selon les instructions du séquenceur ou de
l'unité de commande...
Je pensais que IP n'était employé que pour les fonctions vers les
pointeurs. Et c'est pourquoi je n'ai pas fait le lien en
premier'depuis le début de cette discussion et votre réponse) avec les
fonctions de récursivité qui ne sont pas des fonctions vers les
pointeurs.
Peut-être c'est un autre sujet, mais une fonction vers un pointeur
pourrait rendre l'appel d'une fonction récursive plus rapide?
Merci,
Pascal
Au premier appel f(3), immédiatement f est relancée par l'appel f(2) qui
lui même est relancé par f(1) qui à nouveau appelle f(0). C'est
l'empilement des appels. Donc pour chacun de ces appels, l'exécution de
la fonction f s'est arrêté à la ligne suivante :
Bonjour,
J'ai pu comprendre le concept de récursivité avec votre explication.
Je comprends également que pour comprendre des récursions plus
"sophistiquées", une compréhension de ce qui se passe en compilation/
assembleur est nécessaire. Je pense à l'accès des données en mémoire.
Je ne suis pas encore là, je souhaiterais sortir de ce livre sur
l'architecture des ordinateurs pour passer à la pratique mais si je
vais trop vite, je pense que je devrais retourner à ce livre (et
puisl'inconvénient d'etre autodidacte; il y a aussi le manque de
motivation). Mais selon ce qui est dit dans cette discussion,
comprendre la récursivité permet de comprendre for et while ...
Ce livre n'est pas à coté maintenant mais j'ai en mémoire d'un
pointeur IP ou quelque chose comme ca qui "empile" le résultat des
fonctions dans le stack ou heap je crois et retourne à l'adresse d'une
données dans un buffer selon les instructions du séquenceur ou de
l'unité de commande...
Je pensais que IP n'était employé que pour les fonctions vers les
pointeurs. Et c'est pourquoi je n'ai pas fait le lien en
premier'depuis le début de cette discussion et votre réponse) avec les
fonctions de récursivité qui ne sont pas des fonctions vers les
pointeurs.
Peut-être c'est un autre sujet, mais une fonction vers un pointeur
pourrait rendre l'appel d'une fonction récursive plus rapide?
Merci,
Pascal
Au premier appel f(3), immédiatement f est relancée par l'appel f(2) qui
lui même est relancé par f(1) qui à nouveau appelle f(0). C'est
l'empilement des appels. Donc pour chacun de ces appels, l'exécution de
la fonction f s'est arrêté à la ligne suivante :
Bonjour,
J'ai pu comprendre le concept de récursivité avec votre explication.
Je comprends également que pour comprendre des récursions plus
"sophistiquées", une compréhension de ce qui se passe en compilation/
assembleur est nécessaire. Je pense à l'accès des données en mémoire.
Je ne suis pas encore là, je souhaiterais sortir de ce livre sur
l'architecture des ordinateurs pour passer à la pratique mais si je
vais trop vite, je pense que je devrais retourner à ce livre (et
puisl'inconvénient d'etre autodidacte; il y a aussi le manque de
motivation). Mais selon ce qui est dit dans cette discussion,
comprendre la récursivité permet de comprendre for et while ...
Ce livre n'est pas à coté maintenant mais j'ai en mémoire d'un
pointeur IP ou quelque chose comme ca qui "empile" le résultat des
fonctions dans le stack ou heap je crois et retourne à l'adresse d'une
données dans un buffer selon les instructions du séquenceur ou de
l'unité de commande...
Je pensais que IP n'était employé que pour les fonctions vers les
pointeurs. Et c'est pourquoi je n'ai pas fait le lien en
premier'depuis le début de cette discussion et votre réponse) avec les
fonctions de récursivité qui ne sont pas des fonctions vers les
pointeurs.
Peut-être c'est un autre sujet, mais une fonction vers un pointeur
pourrait rendre l'appel d'une fonction récursive plus rapide?
Merci,
Pascal
In article <4b127610$0$21957$,
candide wrote:
Tu m'emmerdes. Va chercher dans la biblio. J'emploie des termes precis. Tu
M'a echappe ? mais va te faire foutre ! C'est pas parce que tu veux
Le code plus ou moins standard du pgcd récursif est :
"plus ou moins". c'est juste une autre facon d'ecrire la meme chose.
Tu l'as recopie de quelque part, pour dire que c'est standard ? ou tu
arrives
encore a inventer trois lignes de code sans les repiquer ailleurs ?
La j'avoue, la coupe est pleine. J'en ai plus que marre de tes frasques.
A force de jouer au "candide" qui reprend tout et tout le monde en jouant
ta mouche du coche, et en voulant imposer aux gens ta vision etriquee du
monde, tu as finalement reussi a m'enerver un peu.
M'en fous, a troll, troll-et-demi. J'ai la peau plus solide que toi. Si tu
cherches la bagarre...
In article <4b127610$0$21957$426a74cc@news.free.fr>,
candide <candide@free.invalid> wrote:
Tu m'emmerdes. Va chercher dans la biblio. J'emploie des termes precis. Tu
M'a echappe ? mais va te faire foutre ! C'est pas parce que tu veux
Le code plus ou moins standard du pgcd récursif est :
"plus ou moins". c'est juste une autre facon d'ecrire la meme chose.
Tu l'as recopie de quelque part, pour dire que c'est standard ? ou tu
arrives
encore a inventer trois lignes de code sans les repiquer ailleurs ?
La j'avoue, la coupe est pleine. J'en ai plus que marre de tes frasques.
A force de jouer au "candide" qui reprend tout et tout le monde en jouant
ta mouche du coche, et en voulant imposer aux gens ta vision etriquee du
monde, tu as finalement reussi a m'enerver un peu.
M'en fous, a troll, troll-et-demi. J'ai la peau plus solide que toi. Si tu
cherches la bagarre...
In article <4b127610$0$21957$,
candide wrote:
Tu m'emmerdes. Va chercher dans la biblio. J'emploie des termes precis. Tu
M'a echappe ? mais va te faire foutre ! C'est pas parce que tu veux
Le code plus ou moins standard du pgcd récursif est :
"plus ou moins". c'est juste une autre facon d'ecrire la meme chose.
Tu l'as recopie de quelque part, pour dire que c'est standard ? ou tu
arrives
encore a inventer trois lignes de code sans les repiquer ailleurs ?
La j'avoue, la coupe est pleine. J'en ai plus que marre de tes frasques.
A force de jouer au "candide" qui reprend tout et tout le monde en jouant
ta mouche du coche, et en voulant imposer aux gens ta vision etriquee du
monde, tu as finalement reussi a m'enerver un peu.
M'en fous, a troll, troll-et-demi. J'ai la peau plus solide que toi. Si tu
cherches la bagarre...
J'interviens su r ce forum de manière irrégulière, pour l'instant je
concentre mes efforts vers les algorithmes. Je me concentre vers le
langage assembleur. Je ne veux pas approfondir. Avant d'aller plus
loin dans la programmation, je veux comprendre ce qui se passe dans la
machine tant que c'est à "porter de mains".
En fait, je ne viens pas sur ce forum pour savoir ce qui serait bien
pour les intestins ou le foi. J'ai quand même du mal à imaginer que le
langage C est inutile.
J'interviens su r ce forum de manière irrégulière, pour l'instant je
concentre mes efforts vers les algorithmes. Je me concentre vers le
langage assembleur. Je ne veux pas approfondir. Avant d'aller plus
loin dans la programmation, je veux comprendre ce qui se passe dans la
machine tant que c'est à "porter de mains".
En fait, je ne viens pas sur ce forum pour savoir ce qui serait bien
pour les intestins ou le foi. J'ai quand même du mal à imaginer que le
langage C est inutile.
J'interviens su r ce forum de manière irrégulière, pour l'instant je
concentre mes efforts vers les algorithmes. Je me concentre vers le
langage assembleur. Je ne veux pas approfondir. Avant d'aller plus
loin dans la programmation, je veux comprendre ce qui se passe dans la
machine tant que c'est à "porter de mains".
En fait, je ne viens pas sur ce forum pour savoir ce qui serait bien
pour les intestins ou le foi. J'ai quand même du mal à imaginer que le
langage C est inutile.
Bonjour,
Ceci dit, pour quelqu'un qui n'est pas informaticien (comme moi) et
qui ne pratique pas la programmation de manière régulière, il ne faut
pas s'attendre à pouvoir programmer en C correctement avant plusieurs
années (pratiquement dix ans dans mon cas mais je suis une
feignasse ;-) ).
Bonjour,
Ceci dit, pour quelqu'un qui n'est pas informaticien (comme moi) et
qui ne pratique pas la programmation de manière régulière, il ne faut
pas s'attendre à pouvoir programmer en C correctement avant plusieurs
années (pratiquement dix ans dans mon cas mais je suis une
feignasse ;-) ).
Bonjour,
Ceci dit, pour quelqu'un qui n'est pas informaticien (comme moi) et
qui ne pratique pas la programmation de manière régulière, il ne faut
pas s'attendre à pouvoir programmer en C correctement avant plusieurs
années (pratiquement dix ans dans mon cas mais je suis une
feignasse ;-) ).
candide a écrit :Il y a plein de programmeurs C (C ou autre) qui n'ont jamais rien
compris à la récursivité donc te crois pas obligé de passer par ce
pensum (qui est aussi une belle tarte à la crème).
La "tarte à la crème" c'est de faire croire qu'on peut se dispenser de
comprendre la récursivité quand on est programmeur. Ceci est totalement
faux.
Tout algorithme qui requiert un automate à pile est souvent beaucoup
plus facile à coder de façon récursive (exemple : la reconnaissance
syntaxique des expressions arithmétiques).
Et puis nombre d'algorithmes sur les arbres, voire les listes, sont bien
plus faciles à programmer de façon récursive.
La récursivité est un concept clé de la programmation (et de
l'informatique et des mathématiques en général).
candide a écrit :
Il y a plein de programmeurs C (C ou autre) qui n'ont jamais rien
compris à la récursivité donc te crois pas obligé de passer par ce
pensum (qui est aussi une belle tarte à la crème).
La "tarte à la crème" c'est de faire croire qu'on peut se dispenser de
comprendre la récursivité quand on est programmeur. Ceci est totalement
faux.
Tout algorithme qui requiert un automate à pile est souvent beaucoup
plus facile à coder de façon récursive (exemple : la reconnaissance
syntaxique des expressions arithmétiques).
Et puis nombre d'algorithmes sur les arbres, voire les listes, sont bien
plus faciles à programmer de façon récursive.
La récursivité est un concept clé de la programmation (et de
l'informatique et des mathématiques en général).
candide a écrit :Il y a plein de programmeurs C (C ou autre) qui n'ont jamais rien
compris à la récursivité donc te crois pas obligé de passer par ce
pensum (qui est aussi une belle tarte à la crème).
La "tarte à la crème" c'est de faire croire qu'on peut se dispenser de
comprendre la récursivité quand on est programmeur. Ceci est totalement
faux.
Tout algorithme qui requiert un automate à pile est souvent beaucoup
plus facile à coder de façon récursive (exemple : la reconnaissance
syntaxique des expressions arithmétiques).
Et puis nombre d'algorithmes sur les arbres, voire les listes, sont bien
plus faciles à programmer de façon récursive.
La récursivité est un concept clé de la programmation (et de
l'informatique et des mathématiques en général).
Dernier point: en embarque la vitesse n'est pas le problème. Les mhz
sont souvent là plus que nécéssaire (80Mhz pour traiter des trucs qui
arrivent à une freq de 5khz ca le fait les doigts dans le nez), mais ce
qui coince c'est la ROM et la RAM. Elles sont toutes petites en
embarqué, et on préfère de loin, mais vraiment de loin, optimiser en
taille (rom/ram) qu'en vitesse.
Dernier point: en embarque la vitesse n'est pas le problème. Les mhz
sont souvent là plus que nécéssaire (80Mhz pour traiter des trucs qui
arrivent à une freq de 5khz ca le fait les doigts dans le nez), mais ce
qui coince c'est la ROM et la RAM. Elles sont toutes petites en
embarqué, et on préfère de loin, mais vraiment de loin, optimiser en
taille (rom/ram) qu'en vitesse.
Dernier point: en embarque la vitesse n'est pas le problème. Les mhz
sont souvent là plus que nécéssaire (80Mhz pour traiter des trucs qui
arrivent à une freq de 5khz ca le fait les doigts dans le nez), mais ce
qui coince c'est la ROM et la RAM. Elles sont toutes petites en
embarqué, et on préfère de loin, mais vraiment de loin, optimiser en
taille (rom/ram) qu'en vitesse.
