Newsgroup: it.comp.lang.c
Titolo: rilascio memoria

supponete di avere una struttura dati ad albero, di definire:
tipoalbero *radice;
su di essa fate inserzioni e cancellazioni.
nel momento in cui rilascio la memoria... è lecito:
free(&radice);
??
in fase di compilazione (borland c) non ho nessun problema...ma in
realtà non capisco se viene rilasciata tutta la memoria...o solo
quella della radice.

 in fase di compilazione (borland c) non ho nessun problema...
Certo che ce l'hai, solo che non te ne accorgi.
Quello che hai scritto è errato.  Ammesso di aver allocato memoria per
'radice', bisogna liberarla con:
  free(radice);
e NON:
  free(&radice);
perché in questo secondo caso stai cercando di liberare la memoria
allocata dal sistema per la *variabile* puntatore.
In ogni caso, la liberazione dei nodi dell'albero la devi fare tu
MANUALMENTE: il sistema conosce solo i puntatori e non sa nulla di ciò a
cui essi puntano; se nella memoria allocata per un puntatore, c'è un altro
puntatore, la memoria puntata da quest'ultimo non viene deallocata
all'atto della liberazione della memoria puntata dal primo.
-- 
questo articolo e` stato inviato via web dal servizio gratuito 
http://www.newsland.it/news
 segnala gli abusi ad 
ab...@newsland.it

quindi potrebbe funzionare qualcosa del genere:
typedef struct elenco{
        ranking *elem;
        struct elenco *left;
        struct elenco *right;
        }player;
(elem punta a una struttura precedentemente definita)
player *radice=NULL;
doppo le inserzioni per il rilascio della memoria uso
dealloca(root1);
dove
void dealloca(player *p){
  if(p!=NULL){
    dealloca(p->left);
    dealloca(p->right);
    free(p);
  }
} 
che ne pensi??

 che ne pensi??
Va bene.


 } 
...precisazione puramente 'tecnica' (ignorarla pure se vuoi) :-)
La ricorsione e' la soluzione "piu' elegante" ma, ovviamente:
- su sistemi op. che non hanno particolari limiti di stack
- le performance diminuiscono rispetto ad un semplice ciclo 'in linea'
<nota_pragmatica>
...bene se e' un esame. Ma al lavoro userei quanto piu' "possibile": 
for(..;..;..) free(...);
...a meno che, dalla ricorsione, non derivi un oggettivo vantaggio (eg. 
una evidente -e talvolta estrema- semplificazione del codice scritto) e 
gli svantaggi siano comunque trascurabili.
</nota_pragmatica>
ciao
-- 
Cybertoldo
Per rispondermi via email, sostituisci moc.liamg con 
gmail.com

 </nota_pragmatica>
Una meta-precisazione :): in generale, comunque, non č detto che un 
algoritmo ricorsivo sia (cosě) meno efficiente della sua versione iterativa.
La ricorsione puň essere estremamente ottimizzata dal compilatore in
casi particolari (non in questo specifico), ovvero in caso di una
funzione tail-recursive che puň essere "tradotta" in forma iterativa
eliminando le chiamate successive e la creazione di stack frame (tail
recursion elimination).
Un'altra ottimizzazione che puň essere fatta č la "tail call
elimination" che consente di "riciclare" lo stack corrente.
Ciao.

 elimination" che consente di "riciclare" lo stack corrente.
Ottima meta-precisazione. Pero' anche qui, nella pratica, si deve 
conoscere il sistema (comprendendoci anche la capacita' del compilatore) 
in cui andiamo ad implementare. Se sappiamo gia' che il compilatore 
riesce ad ottimizzare lo risorse dello stack e ad espandere *bene* /in 
linea/ il codice ricorsivo... allora e' ovvio che la precisazione che ho 
fatto prima io perde di qualunque importanza... :)
Ciao


fatto prima io perde di qualunque importanza... :)
La precisazione che hai fatto č corretta e importante, ma č
altrettanto vero che su gran parte delle architetture disponibili, sia
il consumo di memoria eventualmente maggiore, che la perdita di
performance č trascurabile.  La ricorsione resta, secondo me, uno dei
metodi piů semplici, intuitivi e sicuri di implementare un algoritmo
di trattazione di strutture dati per natura ricorsive (come gli alberi
o le liste).

 o le liste).
...io "amo" gli algoritmi ricorsivi... tanto per non essere frainteso :-)


 elimination" che consente di "riciclare" lo stack corrente.
Tempo fa lessi un articolo in proposito molto interessante:
http://www.ddj.com/184410590
ciao
Giacomo