-- zwim. Rien n'est impossible que la mesure de la volonté humaine...
bpascal123
Merci zwim,
J'avais le sentiment de quelque chose de récursif dans le résultat mais je n'ai pas encore abordé le chapitre des fonctions en tant qu'autodidacte en programmation. En plus, le site d'où le code vient n'abuse pas des commentaires. Je pense ils ont juste balancé du code de différents langages pour ceux qui ont déjà de bonnes bases.
Pour ton code, la récursivité est plus apparente que le code que j'ai posté dans le sens qu'à l'intérieur d'une fonction, tu appelles cette fonction : void g(int n) { ... g(n-1); ...}
Je comprendrais certainement mieux quand j'aborderais le chapitre des fonctions.
Merci, Pascal
Merci zwim,
J'avais le sentiment de quelque chose de récursif dans le résultat
mais je n'ai pas encore abordé le chapitre des fonctions en tant
qu'autodidacte en programmation. En plus, le site d'où le code vient
n'abuse pas des commentaires. Je pense ils ont juste balancé du code
de différents langages pour ceux qui ont déjà de bonnes bases.
Pour ton code, la récursivité est plus apparente que le code que j'ai
posté dans le sens qu'à l'intérieur d'une fonction, tu appelles cette
fonction : void g(int n) { ... g(n-1); ...}
Je comprendrais certainement mieux quand j'aborderais le chapitre des
fonctions.
J'avais le sentiment de quelque chose de récursif dans le résultat mais je n'ai pas encore abordé le chapitre des fonctions en tant qu'autodidacte en programmation. En plus, le site d'où le code vient n'abuse pas des commentaires. Je pense ils ont juste balancé du code de différents langages pour ceux qui ont déjà de bonnes bases.
Pour ton code, la récursivité est plus apparente que le code que j'ai posté dans le sens qu'à l'intérieur d'une fonction, tu appelles cette fonction : void g(int n) { ... g(n-1); ...}
Je comprendrais certainement mieux quand j'aborderais le chapitre des fonctions.
Merci, Pascal
candide
a écrit :
J'avais le sentiment de quelque chose de récursif dans le résultat mais je n'ai pas encore abordé le chapitre des fonctions en tant qu'autodidacte en programmation.
Tu n'as pas abordé la question des fonctions en C et tu as ouvert un fil sur fgets() ? c'est pas vraiment logique, apprendre c'est comme une recette de cuisine, il suffit pas d'avoir les bons ingrédients faut aussi les utiliser dans le bon ordre ;) Faut reconnaître aussi que les livres ne sont pas un modèle de logique en la matière.
Pour ton code, la récursivité est plus apparente que le code que j'ai posté dans le sens qu'à l'intérieur d'une fonction, tu appelles cette fonction : void g(int n) { ... g(n-1); ...}
C'est de la récursivité croisée. Franchement, le code donné est très artificiel, c'est vraiment un exercice de style et qui ne sert quasiment jamais dans la pratique, le genre de code qui n'a pour effet que de décourager le débutant et lui faire prendre la proie pour l'ombre.
Je comprendrais certainement mieux quand j'aborderais le chapitre des fonctions.
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).
bpascal123@googlemail.com a écrit :
J'avais le sentiment de quelque chose de récursif dans le résultat
mais je n'ai pas encore abordé le chapitre des fonctions en tant
qu'autodidacte en programmation.
Tu n'as pas abordé la question des fonctions en C et tu as ouvert un fil
sur fgets() ? c'est pas vraiment logique, apprendre c'est comme une
recette de cuisine, il suffit pas d'avoir les bons ingrédients faut
aussi les utiliser dans le bon ordre ;) Faut reconnaître aussi que les
livres ne sont pas un modèle de logique en la matière.
Pour ton code, la récursivité est plus apparente que le code que j'ai
posté dans le sens qu'à l'intérieur d'une fonction, tu appelles cette
fonction : void g(int n) { ... g(n-1); ...}
C'est de la récursivité croisée. Franchement, le code donné est très
artificiel, c'est vraiment un exercice de style et qui ne sert quasiment
jamais dans la pratique, le genre de code qui n'a pour effet que de
décourager le débutant et lui faire prendre la proie pour l'ombre.
Je comprendrais certainement mieux quand j'aborderais le chapitre des
fonctions.
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).
J'avais le sentiment de quelque chose de récursif dans le résultat mais je n'ai pas encore abordé le chapitre des fonctions en tant qu'autodidacte en programmation.
Tu n'as pas abordé la question des fonctions en C et tu as ouvert un fil sur fgets() ? c'est pas vraiment logique, apprendre c'est comme une recette de cuisine, il suffit pas d'avoir les bons ingrédients faut aussi les utiliser dans le bon ordre ;) Faut reconnaître aussi que les livres ne sont pas un modèle de logique en la matière.
Pour ton code, la récursivité est plus apparente que le code que j'ai posté dans le sens qu'à l'intérieur d'une fonction, tu appelles cette fonction : void g(int n) { ... g(n-1); ...}
C'est de la récursivité croisée. Franchement, le code donné est très artificiel, c'est vraiment un exercice de style et qui ne sert quasiment jamais dans la pratique, le genre de code qui n'a pour effet que de décourager le débutant et lui faire prendre la proie pour l'ombre.
Je comprendrais certainement mieux quand j'aborderais le chapitre des fonctions.
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).
-ed-
On 26 nov, 01:33, "" wrote:
Bjr,sr, Voici une fonction très simple qui réagit comme s'il y avait une boucle alors qu'en apparence il n'y en a pas :
C'est un appel récursif. Ça se comporte comme une boucle, oui, c'est fait pour ...
Ça n'a rien de 'très simple'...
On 26 nov, 01:33, "bpascal...@googlemail.com"
<bpascal...@googlemail.com> wrote:
Bjr,sr,
Voici une fonction très simple qui réagit comme s'il y avait une
boucle alors qu'en apparence il n'y en a pas :
C'est un appel récursif. Ça se comporte comme une boucle, oui, c'est
fait pour ...
Bjr,sr, Voici une fonction très simple qui réagit comme s'il y avait une boucle alors qu'en apparence il n'y en a pas :
C'est un appel récursif. Ça se comporte comme une boucle, oui, c'est fait pour ...
Ça n'a rien de 'très simple'...
Mickaël Wolff
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).
J'ai du mal à comprendre qu'on puisse se prétendre programmeur et ne rien entendre à la récursivité. Les pointeurs, à la rigueur, je peux comprendre, mais la récursivité ?
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).
J'ai du mal à comprendre qu'on puisse se prétendre programmeur et ne
rien entendre à la récursivité. Les pointeurs, à la rigueur, je peux
comprendre, mais la récursivité ?
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).
J'ai du mal à comprendre qu'on puisse se prétendre programmeur et ne rien entendre à la récursivité. Les pointeurs, à la rigueur, je peux comprendre, mais la récursivité ?
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).
J'ai du mal à comprendre qu'on puisse se prétendre programmeur et ne rien entendre à la récursivité. Les pointeurs, à la rigueur, je peux comprendre, mais la récursivité ?
Moi aussi. Sans la récursivité, fini les structures d'arbres et autres structures de données "sophistiquées".
Souvent la récursivité permet de coder avec peu de ligne des algos qui s'ils sont "dérécursivisés" deviennent super lourds à écrire, gérer, maitenir et qui nécéssitent du support du Runtime ou de l'OS tel que l'allocation de mémoire dynamique.
Dans mon domaine (l'embarqué), les OS n'ont pas toujours d'allocation mémoire dynamique mais ils supportent tous une pile (pour appeller des fonctions il vaut mieux), et dans ce cas la version récursive des algos est préférable à celle qui fait des "malloc()".
Cela dit, dans ce domaine il faut se méfier de la taille de ce que l'on envoi sur la pile car cette dernière n'est pas non plus toujours très grande (256octets à 1k parfois), mais cela permet quand même de travailler sur des structures de données réalistes avec une profondeur raisonnable. En effet si on empile 8 octets à chaque appel (un pointeur de data et l'adresse de retour par exemple), alors il faut a peu près une profondeur de 32 avant de saturer les 256 octets de pile. C'est pas mal du tout finalement.
sam.
Mickaël Wolff a écrit :
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).
J'ai du mal à comprendre qu'on puisse se prétendre programmeur et ne
rien entendre à la récursivité. Les pointeurs, à la rigueur, je peux
comprendre, mais la récursivité ?
Moi aussi. Sans la récursivité, fini les structures d'arbres et autres
structures de données "sophistiquées".
Souvent la récursivité permet de coder avec peu de ligne des algos qui
s'ils sont "dérécursivisés" deviennent super lourds à écrire, gérer,
maitenir et qui nécéssitent du support du Runtime ou de l'OS tel que
l'allocation de mémoire dynamique.
Dans mon domaine (l'embarqué), les OS n'ont pas toujours d'allocation
mémoire dynamique mais ils supportent tous une pile (pour appeller des
fonctions il vaut mieux), et dans ce cas la version récursive des algos
est préférable à celle qui fait des "malloc()".
Cela dit, dans ce domaine il faut se méfier de la taille de ce que l'on
envoi sur la pile car cette dernière n'est pas non plus toujours très
grande (256octets à 1k parfois), mais cela permet quand même de
travailler sur des structures de données réalistes avec une profondeur
raisonnable. En effet si on empile 8 octets à chaque appel (un pointeur
de data et l'adresse de retour par exemple), alors il faut a peu près
une profondeur de 32 avant de saturer les 256 octets de pile. C'est pas
mal du tout finalement.
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).
J'ai du mal à comprendre qu'on puisse se prétendre programmeur et ne rien entendre à la récursivité. Les pointeurs, à la rigueur, je peux comprendre, mais la récursivité ?
Moi aussi. Sans la récursivité, fini les structures d'arbres et autres structures de données "sophistiquées".
Souvent la récursivité permet de coder avec peu de ligne des algos qui s'ils sont "dérécursivisés" deviennent super lourds à écrire, gérer, maitenir et qui nécéssitent du support du Runtime ou de l'OS tel que l'allocation de mémoire dynamique.
Dans mon domaine (l'embarqué), les OS n'ont pas toujours d'allocation mémoire dynamique mais ils supportent tous une pile (pour appeller des fonctions il vaut mieux), et dans ce cas la version récursive des algos est préférable à celle qui fait des "malloc()".
Cela dit, dans ce domaine il faut se méfier de la taille de ce que l'on envoi sur la pile car cette dernière n'est pas non plus toujours très grande (256octets à 1k parfois), mais cela permet quand même de travailler sur des structures de données réalistes avec une profondeur raisonnable. En effet si on empile 8 octets à chaque appel (un pointeur de data et l'adresse de retour par exemple), alors il faut a peu près une profondeur de 32 avant de saturer les 256 octets de pile. C'est pas mal du tout finalement.
sam.
bpascal123
> Tu n'as pas abordé la question des fonctions en C et tu as ouvert un fi l sur fgets() ? c'est pas vraiment logique, apprendre c'est comme une recette de cuisine, il suffit pas d'avoir les bons ingrédients faut aussi les utiliser dans le bon ordre ;) Faut reconnaître aussi que les livres ne sont pas un modèle de logique en la matière.
A mon niveau, je distingue les fonctions "toutes faites" qui vont avec stdio.h, string.h ... des fonctions que l'on "fabrique" avec prototype, déclaration, définition... Je ne suis pas entièrement sû re de ce que je dis mais je pense que ça explique en tant que débutant, j'ai commencé avec les fonctions des librairies standards.
> Tu n'as pas abordé la question des fonctions en C et tu as ouvert un fi l
sur fgets() ? c'est pas vraiment logique, apprendre c'est comme une
recette de cuisine, il suffit pas d'avoir les bons ingrédients faut
aussi les utiliser dans le bon ordre ;) Faut reconnaître aussi que les
livres ne sont pas un modèle de logique en la matière.
A mon niveau, je distingue les fonctions "toutes faites" qui vont avec
stdio.h, string.h ... des fonctions que l'on "fabrique" avec
prototype, déclaration, définition... Je ne suis pas entièrement sû re
de ce que je dis mais je pense que ça explique en tant que débutant,
j'ai commencé avec les fonctions des librairies standards.
> Tu n'as pas abordé la question des fonctions en C et tu as ouvert un fi l sur fgets() ? c'est pas vraiment logique, apprendre c'est comme une recette de cuisine, il suffit pas d'avoir les bons ingrédients faut aussi les utiliser dans le bon ordre ;) Faut reconnaître aussi que les livres ne sont pas un modèle de logique en la matière.
A mon niveau, je distingue les fonctions "toutes faites" qui vont avec stdio.h, string.h ... des fonctions que l'on "fabrique" avec prototype, déclaration, définition... Je ne suis pas entièrement sû re de ce que je dis mais je pense que ça explique en tant que débutant, j'ai commencé avec les fonctions des librairies standards.
-ed-
On 26 nov, 13:26, "" wrote:
A mon niveau, je distingue les fonctions "toutes faites" qui vont avec stdio.h, string.h ... des fonctions que l'on "fabrique" avec prototype, déclaration, définition... Je ne suis pas entièrement s ûre de ce que je dis mais je pense que ça explique en tant que débutant, j'ai commencé avec les fonctions des librairies standards.
Et tu as tout à fait raison... J'ai failli répondre directement à Candide, mais j'ai préféré que ça vienne de toi !
On 26 nov, 13:26, "bpascal...@googlemail.com"
<bpascal...@googlemail.com> wrote:
A mon niveau, je distingue les fonctions "toutes faites" qui vont avec
stdio.h, string.h ... des fonctions que l'on "fabrique" avec
prototype, déclaration, définition... Je ne suis pas entièrement s ûre
de ce que je dis mais je pense que ça explique en tant que débutant,
j'ai commencé avec les fonctions des librairies standards.
Et tu as tout à fait raison... J'ai failli répondre directement à
Candide, mais j'ai préféré que ça vienne de toi !
A mon niveau, je distingue les fonctions "toutes faites" qui vont avec stdio.h, string.h ... des fonctions que l'on "fabrique" avec prototype, déclaration, définition... Je ne suis pas entièrement s ûre de ce que je dis mais je pense que ça explique en tant que débutant, j'ai commencé avec les fonctions des librairies standards.
Et tu as tout à fait raison... J'ai failli répondre directement à Candide, mais j'ai préféré que ça vienne de toi !
candide
-ed- a écrit :
On 26 nov, 13:26, "" wrote:
A mon niveau, je distingue les fonctions "toutes faites" qui vont avec stdio.h, string.h ... des fonctions que l'on "fabrique" avec prototype, déclaration, définition... Je ne suis pas entièrement sûre de ce que je dis mais je pense que ça explique en tant que débutant, j'ai commencé avec les fonctions des librairies standards.
Et tu as tout à fait raison...
si son but est de ne pas arriver à apprendre le C, il est effectivement sur la bonne voie.
-ed- a écrit :
On 26 nov, 13:26, "bpascal...@googlemail.com"
<bpascal...@googlemail.com> wrote:
A mon niveau, je distingue les fonctions "toutes faites" qui vont avec
stdio.h, string.h ... des fonctions que l'on "fabrique" avec
prototype, déclaration, définition... Je ne suis pas entièrement sûre
de ce que je dis mais je pense que ça explique en tant que débutant,
j'ai commencé avec les fonctions des librairies standards.
Et tu as tout à fait raison...
si son but est de ne pas arriver à apprendre le C, il est effectivement
sur la bonne voie.
A mon niveau, je distingue les fonctions "toutes faites" qui vont avec stdio.h, string.h ... des fonctions que l'on "fabrique" avec prototype, déclaration, définition... Je ne suis pas entièrement sûre de ce que je dis mais je pense que ça explique en tant que débutant, j'ai commencé avec les fonctions des librairies standards.
Et tu as tout à fait raison...
si son but est de ne pas arriver à apprendre le C, il est effectivement sur la bonne voie.