Prendiamo l'esempio classico del fattoriale:
Codice: Seleziona tutto
#include <stdio.h>
unsigned int fact (int n) *1
{
if (n<=1) *2
return 1;
else {
return n*fact(n-1);} *3
}
int main (void) {
int x=3;
printf " %u\n",fact(x)); *4
return 0;}A parte il fatto che con un ciclo for, si potrebbe risolvere subito, ma da come ho capito la ricorsione a volte è l'unico modo, e in più "fa" ragionare in modo diverso.
Comunque, nel main, passo alla funzione fact il numero 3.
Quando la chiamata viene eseguita (punto *2) la condizione non viene soddisfatta, quindi si salta al punto *3, che a sua volta chiama la funzione fact (punto *1),
che a sua volta non è soddisfatta, finchè n è <=1.
Quando n è <=1 la condizione è soddifatta, e viene ritornato 1.
Ma 1 ritorna al punto *4?
Il mio libro dice:
"...osservate che le chiamate non terminate di fact "s'impilano" fino a quando alla funzione fact non viene passato un 1.
A questo punto le vecchie chiamate a fact iniziano a "srotolarsi" una a una fino a quando la chiamata originale (fact(3)) restituisce il risultato ...."
Non capisco questo!!! Srotolarsi, implica il fatto che le chiamate restino "congelate" e/o "memorizzate" da qualche parte, no? Azzardo: nello stack, nella heap...bo!!!
Come se si nidificassero una dopo l'altra...non riesco proprio a capire.
Ammesso che sia come ho detto sopra, che vantaggi avrei rispetto a un ciclo for??? Molto più veloce e immediato.
Mi confonde parecchio le righe del mio libro che ho scritto sopra.
Se qualcuno mi desse una mano...
Non mi va di non capire la ricorsione, magari non la si usa spesso, ma credo (letture qua e la) che alcuni problemi siano dei rompicapo in modo iterativo, mentre la ricorsione semplifica molto.
Ma ahimè, non è così immediata da capire come invece dicono i testi.
Grazie a tutti in anticipo
) con degli algoritmi ricorsivi. Cerca di velocizzare sempre di più il crash, così si impara bene 
). 
x vale sempre 3, anche se il passaggio dei parametri fosse à la LISP!