Newsgroup: it.comp.lang.javascript
Titolo: removeChild: gestione memoria

Chi mi sa dire cosa succede ai "nipoti" del figlio che elimino con una
removeChild?
Mi spiego meglio:
<libro>
    <capitolo id= "questo">
        <para> ggggggggg </para>
        <para> lffffffff</para>
        <para> laaaaaa </para>
    </capitolo>
    <capitolo>
        <para> l111111111</para>
    </capitolo>
</libro>
se faccio una document.removeChild(document.getElementById("questo"));
Che fine fanno tutti i nodi <para> (e i textNode figli di ogni <para>)?
Non sono piů agganciati all'albero... ma a spazio in memoria come siamo
messi?
Il fatto č che la removeChild ritorna il nodo rimosso,  ma non ho capito se
a questo resta agganciato l'eventuale sottoalbero di cui č la radice.
In ogni caso il nodo rimosso in memoria ancora č presente... come faccio ad
abbatterlo definitivamente?
E per abbatere anche i figli?
--Gabriele

Dovrebbe pensarci il Garbage Collector
Alex.
-- 
___________________________________________________________
a p bertolini
"Se Dio è perfetto, perché ha creato le funzioni discontinue?"
#ICQ: 10681264
(
www.webwarrior.org
)

> Dovrebbe pensarci il Garbage Collector
Quindi non me ne devo curare ! :)
--Gabriele

Nel mondo a oggetti, visto che esiste solo il metodo new() (mancano metodi tipo dispose(),  ecc.) puoi tranquillamente lasciare i
piatti sporchi nel lavello che tanto passa la domestica :-)


piatti sporchi nel lavello che tanto passa la domestica
bè in c++ mi pare che c'è abbondantemente il concetto di costruttore e
distruttore (ogni oggetto comunque come dici tu ne ha uno di default).
Mi pare però che, come si invoca il costrutture con specifico comando lo si
fa anche per il distruttore.
Una volta avevo aperto un thread sui distruttori in JS su questo NG, ma mi
pare non mi avesse risposto nessuno.
Comunque,  tutto questo è piuttosto OT :-)
Ciao.
--Gabriele

 pare non mi avesse risposto nessuno.
Non esistono i distruttori in Javascript.. ha una sorta di GC.
La memoria se la gestisce da solo, pastrocchi con ActiveX a parte su 
mondo Windows.
-- 
C'ya,
ZER0 :: coder.gfxer.webDesigner();
"When you have eliminated the impossible, whatever remains,
however improbable, must be the truth." (S.H.)

 In ogni caso il nodo rimosso in memoria ancora è presente...
Se non gli associ un riferimento, il GC dovrebbe eliminarlo.
Ovvero, a meno che tu non faccia:
var x=mynode.removeChild(nodechild);


 ha scritto nel messaggio news:Zllcb.344309$Ny5.10...@twister2.libero.it...


 per quanto riguarda il GC.. Il c++ proprio non ce l'ha.
Forse non mi ero spiegato... replicavo solo all'affermazione che nei
linguaggi ad oggetti è automatico avere "una domestica" che ti lava i piatti
sporchi.
A tal proposito dicevo che, anche se il C++ è un linguaggio ad oggetti (anzi
forse è il papà dei linguaggi ad oggetti???), la memoria è meglio
liberarsela da soli quando non abbiamo più bisogno di un oggetto.
Come dici tu infatti NON esiste in C++ un meccanismo che si "spazzola" gli
oggetti non è più referenziati, rendendo le relative locazioni  nuovamente
disponibili per l'uso.
Infatti C++ mette a disposizione l'istruzione delete per rimuovere gli
oggetti craeti in precedenza con una new.
JS a quanto pare se la sbriga da solo :-)
Ciao.
--Gabriele

 della mia opinione.
Non mi piace neanche a me, l'ho solo tirato fuori in  quanto stavano fuori
il discorso "oggetti".
Si comunque hai ragione riguardo al fatto di essere un po di qua e un po di
la...
--Gabriele

 il discorso "oggetti".
Il C++ se li pappa a colazione i "linguaggi ad oggetti".
Non solo e' versatile da far spavento, ma le performance non sono 
paragonabili, per non contare gli innumerevoli modi per ottimizzare che 
ci sono, che qualsiasi altro "linguaggio ad oggetti" si scorda.
Inoltre e' L'UNICO che possiede l'eredita' multipla.
Il Java ed il C# sono nati per essere usati in modo piu' semplice, e 
limitare i "danni" che un programmatore poteva fare.
Bah. E' ovvio che se si manipola direttamente la memoria con i puntatori 
si deve stare attenti, ma cribbio: Un programmatore dovrebbe essere 
tranquillamente in grado di gestire queste cose. Altrimenti che 
programmatore e' ?
.. Piu' vado avanti, piu' mi accorgo che la "vecchia scuola" e' sempre 
piu' rara..


 JS a quanto pare se la sbriga da solo :-)
Ma non sempre le cose vanno come dovrebbero. Infatti in Java e' 
possibile invocare il GC anche a manino.
Cosa del tutto inutile, se funzionasse davvero a dovere, non ti pare? :P


 Non e' una caratteristica della OOP.
E' proprio questo che intendevo dire: l'associazione linguaggio ad oggetti e
GC non è affatto scontata...
--Gabriele

 piu' rara..
Il basic dell'MSX 64k puo' essere parte della vecchia scuola... che bellezza
a suon di GOTO e GOSUB.
A parte gli scherzi credo che il kernigan richie (si scrive cosě?) sia una
conoscenza indispensabile per iniziare a programmare. (che ficata i
puntatori) e i segmentation fault! :-)
Poi ho provato con lo Stroustup per il C++ ... nulla da fare : troppo
complicato questo C++.
:-P
Ciao.
--Gabriele

 piu' rara..
Vedessi le università! Non fanno nemmeno Pascal, e quasi nemmeno il C. Studiano Java già in Programmazione I

core dump.
Altro che lo script debugger.

, 
gabriele....@libero.it
 says...

Ehò, a questo giro non ci si doveva proprio intendere, si vede. :)
(E' probabile che sia complice anche la mia insonnia coatta) 


 :-P
Boh.. che dirti? A me il C++ e' parso una gran figata. Anche perche' 
puoi benissimo programmare in C, usando solo cio' che ti serve del C++ 
(io ad esempio faccio cosi'. Niente cout, etc..)


 Vedessi le università! Non fanno nemmeno Pascal, e quasi nemmeno il C. Studiano Java già in Programmazione I
Vabbe', dai. Questo lo posso capire. Java e' perfetto a scopo didattico.


 Altro che lo script debugger.
Tra l'altro in JS1.5 c'e' nativamente la funzione di dump. ;)
(ovvio, non ti fa il dump della memoria, stampa solo una stringa su 
console)


 liberarsela da soli quando non abbiamo più bisogno di un oggetto.
perché farlo manualmente quando negli ambienti più recenti (JRE, .NET CLR e
varianti open source) ci sono efficientissimi algoritmi di ottimizzazione
che ci pensano per te? Tranquillo, concentrati sul disegno dell'applicazione
--
artemis.alpeia (en España)
--------------------------------
Inviato via 
http://usenet.libero.it

 Tranquillo, concentrati sul disegno dell'applicazione
Si puo' fare benissimo entrambi.
Anche se pure qui, ripeto, "the right tool for the right job".


 che ci pensano per te?
In linea di principio, però, si parla sempre di processo demone che verifica lo stato ad intervalli regolari (amenoché le cose siano
cambiate di recente).
Questo si traduce inevitabilmente in maggiori consumi di CPU e RAM. Non è possibile infatti che anche con processori di oggi (che
fanno sembrare un CRAY un cellulare) i programmi girano lenti!
Alex.

 su disco), e' anche per questo motivo.
colpa di certi ambienti di programmazione che hanno spinto il mercato in
quella direzione


 quella direzione
E' quel che ho detto ^_^
