Reprise du message précédent :

Je parlais de sa fonction postée le 28 mai...

non je sais, pas je ne comprends pas trop ce précept. ça me rappelle le pascal. Et je n'aime pas ta manière de structurer : ça donne des dizaines de if imbriqués parce que tu préfères tout à un return. question de goût.

bof. ici il faut respecteur l'ordre d'appel. seulement c'est facile de faire le free avant le free_list et ça devient terminal.

Ben oui, mais ça ne fonctionne plus. (histoire de branche, de scie...)
 
Si j'ai donnée cet exemple c'est qu'à ma connaissance (faible en Théorie de l'Information), cette fonction n'est pas récursive terminale. Elle fonctionne justement sur le principe de l'empilage et de l'exécution inverse. On descend très profond pour atteindre la fin de la liste en empilalnt les adresses à libérer, et lors des returns implicites, tous les free() sont appelés dans l'ordre inverse. Mais pour ça, il faut obligatoirement de la pile (mémoire auto). Comme elle est incontrôlable de manière portable (oui, il existe des extensions), risque de décès prématuré par explosion de la mémoire automatique...
 
Mais je serais heureux qu'on me prouve que je me trompe.

En ce qui me concerne, ça m'a toujours permi d'écrire du code robuste, lisible et maintenable. Ca me suffit.
 
Par contre quasiment à chaque fois que je suis tombé sur du code non structuré, j'ai trouvé des bugs (ressources non libérées ou libérées 2 fois, valeur de retour non initialisées...), ou des redondances...

Avec un appel de fonction après l'appel récursif ? Tu peux le prouver ? J'ai cru comprendre que seule la récursion terminale était 'aplatissable' ?
 

 
Arf ma question était de savoir s'ils savaient le faire pour de la terminale justement
 
Effectivement la fonction que t'as posé en dessous ne l'est pas. (Ca me fait bizarre de parler de ca en C, des souvenirs de Scheme qui remontent à la surface ) et dans tout les cas il ne pourra pas l'applatir.

euh ça fonctionne pas ça ?

 
Bha la c'est une récursive terminale.
Dans un cas comme ca, le compilo arrive à générer du code qui fasse pas péter la pile ou il reste sur l'implémentation naive ?

Ben si, mais ça doit être laid, autant écrire directement la version itérative...

On est tous d'accord pour dire que la récursivité caipalapanacai... Il faut néanmoisn ne pas se voiler la face, ca rends des services dans des domaines et des applications bien DEFINIS !  
 
Voial, loin de moi l'idée d'en mettre partout mais quand ca :
1/ simplifie l'ecriture
2/ ne pete pas la pile
3/ reste compréhensible vis à vis du probleme.
Ca me va.  
 
Un probleme naturellement récursif, autant l'ecrire comme telle (parcours d'arbre etc ... par exemple). Par contre si les perfs (vitesse OU memoire) deviennent mauvaise, alors faudra penser à reecrire ça  "à plat". Le compilo il sait pas faire :s

De toute façon, si lers perfs deviennent mauvaises, en dérécursivant (si c'est un véritable programme récursif, pas un de ceux qui se résolvent par une simple itération), souvent on aura besoin de piles ou de files, avec gestion mémoire, cà ralentira quand même, la seule différence c'est qu'on fera appel à la mémoire globale, plus à la pile, donc moins de risque.
 
Et pis la récursivité c'est beau, c'est élégant    
 
J'attends qu'on dérécursive la fonction d'Ackermann.

 
Personnellement, je suis d'avis d'éviter la récursivité chaque fois qu'on peut. Bon, évidemment, pour un parcours d'arbre c'est impossible (ou alors on simule la récursivité en gérant nous-même l'empilement des variables mais il ne s'agit là que d'un couche de peinture pour masquer la crasse).
 
Certes, une fonction récursive apparaît souvent comme très élégante à écrire "return f(n - 1)" et hop, en 2 lignes c'est torché mais derrière, faut voir ce qu'il se passe. Surtout que quand tu parles de récursivité, tu sous entend probablement "récursivité simple" comme "factorielle" ou "arbre". Mais faut pas oublier qu'on peut avoir aussi des récursivités doubles et là, c'est la cata...
Regarde Fibonacci...
En récursif

 
En itératif

 
En récursif, le simple calcul de "fib(6)" nécessitera l'empilement de

• 1 fois fib(5)
• 2 fois fib(4)
• 3 fois fib(3)
• 5 fois fib(2)
• 8 fois fib(1)
• 13 fois fib(0)

Alors qu'en itératif, le calcul de "fib(6)" se fera dans une simple boucle avec 2 décalages et une addition par tour de boucle.
Essaye de calculer "fib(24)" avec les 2 méthodes et tu comprendras ta douleur...  
 
PS: je viens de regarder Ackerman et là, c'est moi qui contemple ma propre douleur  

euh complité ta version itérative

ou alors c'est juste ton tableau et son joli nom qui embrouille pour rien.

Boaf... pourquoi pas un tableau puisque j'ai 3 valeurs à gérer qui appartiennent à un même ensemble ??? J'ai mis "U" juste en référence aux maths qui parlent souvent de "suite de Fibonacci" et dont les termes sont nommés "Un", Un+1" et "Un+2"
Tu peux évidemment utiliser "a, b et c" si t'as du mal avec les tableaux....