Newsgroup: it.comp.lang.visual-basic
Titolo: [?] La memoria si libera quando si ripete New?

La domanda è abbastanza banale:
se reistanzio più volte un oggetto, in particolare:
Set adoRs = New ADODB.Recordset
se l'oggetto era già esistente si libera la memoria precedentemente occupata
o bisogna premettere un set adors = nothing?
--
Lawrence Lebowsky
#marcone#@#sidsrl#.it


ogni volta che un oggetto non viene più referenziato (ne da VB ne
dall'applicazione) si autodistrugge automaticamente;
quindi
Set adoRs = New ADODB.Recordset    ' crea un oggetto
Set adoRs = New ADODB.Recordset    ' crea un nuovo oggetto, il precedente si
distrugge
Set adoRs2 = adoRs
Set adoRs = New ADODB.Recordset    ' crea un nuovo oggetto, ma il vecchio
ancora esiste perchè referenziato da adoRs2
ciao

dall'applicazione) si autodistrugge automaticamente;
Questo e' vero solo sulla carta: e' meglio non fidarsi delle
disallocazioni automatiche e del runtime, che sappiamo tutti essere
pieno di buchi, piccoli o grandi.
Saluti.
-- 
      Gianni "bugbarbeq" Rondinini, 25, RA, 242, 152
  VBR - Vero Birro Romagnolo®, diffidate dalle imitazioni!
 Opel/ECC Calibrezio EVO-VI --- Kawasaki "Gas Gas" ZZ-R 1100
 ICQ# 36893168 - IRCNet: bugbarbeq, @ on #linux-it & #NetBSD
   On contrary of popular belief, Unix *IS* user friendly:
    it just appears to be selective who it is friend with


Quindi anche quando si fa un erase di un array dinamico di oggetti forse
conviene prima settare a nothing i singoli elementi?
--
Lawrence Lebowsky
#marcone#@#sidsrl#.it


no, non serve, ne per gli array dinamici ne per le collection o dictionary
ciao

 no, non serve, ne per gli array dinamici ne per le collection o dictionary
lo dici perché hai qualche documentazione oppure vai a intuito?
perché ritengo che la domanda di Lawrence sia interessantissima e richieda
uno studio maggiore della solito.
--
Fibia "Sakamoto" FBI
E-mail: 
fibi...@hotmail.com
ICQ UIN 63586057
Sito Personale: 
http://www.geocities.com/fibiafbi
VB Simple: 
http://vbsimple.virtualave.net
Membro #25 delle Mitiche Brigate Takahashi sezione Sud


lo dico xchè COM parla chiaro: se i riferimenti all'oggetto decadono (e
quindi la variabile che li contiene "muore") l'oggetto viene distrutto; è
uno dei pilastri di COM; (per chi ancora non lo sapesse VB si basa per
intero su COM)
cmq per provare si fa davvero presto: creati un oggetto di clase (.cls),
metti nel _Intialize e _Terminate degli opportuni Debug.Print, instanzia
tale oggetto tutte le volte che vuoi, metti i riferimenti a tale oggetti in
un array (o collection o quello che vuoi) poi spazza via l'array, e guarda
cosa succede;
ciao

 intero su COM)
sono d'accordo soltanto sulla via teorica ma non quella pratica.
chi ha visto la prima release del S.C. 2001 sa che problemi si sono
generati.
il classico errore di oggetto istanziato ma non deallocato manualmente ha
generato un collasso dell'intero sistema bloccando per ore intere il nostro
S.C.
TUTTI gli oggetti allocati tramite New o CreateObject devono essere
dealllocati mediante Nothing
incollo un pezzettino da MSDN:
Quando più variabili oggetto si riferiscono a uno stesso oggetto, la memoria
e le risorse di sistema associate all'oggetto al quale si riferiscono le
variabili
saranno rilasciate solo dopo che tutte le variabili oggetto saranno state
impostate su Nothing, in modo esplicito utilizzando Set, oppure in modo
implicito dopo che l'ultima variabile oggetto impostata su Nothing non
rientra
più nell'area di validità.
ma in altre sezioni MSDN sembra dire l'opposto..
mah.. qui ci vorrebbe un controllo della memoria..
d'altronde.. se la deallocazione fosse automatica casa MS non avrebbe mai
messo il set nothing in tutti i suoi esempi, come invece fa.
Ciao



beh, parlando di ASP + VBScript le cose sono un tantino differenti;
prima di tutto per via dello scope (ambito) di validità delle variabili che
possono essere a livello di Session, Application e Server, e in alcuni casi
si può fare facilmente confusione;
inoltre lo stesso VBScript in più di una occasione (parlo per esperienze
personali naturalmente) ha "dato di matto" in situazioni che non avevano,
almeno in teoria, nulla di particolarmente strano;
va da se che, in simili situazioni, è bene non dare nulla per scontato in
modo da evitare brutte sorprese (al max si sarà scritto un po di codice in
più);
ribadisco cmq il fatto che in VB6 non ho mai avuto problemi di sorta con la
distruzione automatica degli oggetti, fatta eccezione per gli oggetti
autoistanziati, cioè quelli creati con
    Dim x As New MyObject
e di conseguenza con le form di default (cioè con la form chiamata Form1 di
tipo Form1, e così via... se si utilizza invece un
    Dim frm As Form1
    Set frm = New Form1
    Load frm
il discorso ovviamente non vale)
ciao


non sono d'accordo: il principio è vero e basta;
se un oggetto malgrado tutto rimane vivo può essere solo per 3 motivi:
1) qualcuno o qualcosa continua a referenziarlo
2) qualcuno lo ha usato male (situazioni di basso livello del tipo non è
stato chiamato il metodo Release dell'interfaccia, ma in VB "standard" non
ci sono problemi di sorta... occhio agli accessi a basso livello ai
riferimenti, ad esempio con la CopyMemory)
3) l'oggetto non è stato implementato ad hoc (leggesi: bug; anche in questo
caso si tratta di situazioni di basso livello  tipiche di C/C++)
purtroppo COM non ha alcun meccanismo per il quale è possibile risalire agli
"utilizzatori" di un oggetto;
una utlima nota riguarda IIS (e quindi VBScript);
per ottimizzare la gestione della memoria IIS dovrebbe avere un meccanismo
"intelligente" (questione di punti di vista...) che ottimizza
l'istanziazione delle DLL utilizzate (e quindi anche delle DLL COM) secondo
il quale una DLL non viene scaricata immediatamente appena il contatore di
utilizzo va a zero, ma attende un certo timeout fisso (mi sembra 5 minuti o
giù di li...) prima di spazzarla via dalla memoria;
le ripercussioni su DLL COM non dovrebbero in ogni caso essere
significative.... anche se in realtà, relativamente a VBScript + ASP, non ci
metterei la mano sul fuoco;
ciao

non sono d'accordo: il principio è vero e basta;
Senza farla cadere tanto dall'alto, quanto tempo e' che programmi?
Credo non poco, e quindi dovresti esserti scontrato anche tu con bug,
buchi, memory leaks e cosi' via di ogni tipo con ogni linguaggio ed
ogni applicazione. Il principio e' vero e basta, ok. La realta' e'
un'altra: ogni tanto, un oggetto non viene automaticamente deallocato.
Perche' se apri e chiudi Word 40 volte la memoria e le risorse di
sistema non tornano quelle che erano? Perche' se apri e chiudi 30
volte Internet Explorer succede lo stesso?
Tutti i programmi hanno buchi, e il sistema operativo di diverso da un
programma ha solo la complessita', che e' enormemente superiore e
quindi ha un numero di buchi enormemente superiore. Ci sono tante
combinazioni sfortunate che fanno si' che un oggetto che dovrebbe
essere automaticamente deallocato in realta' non lo sia: prendere
precauzioni non costa quasi niente -solo un po' di scocciatura-- e
quindi sono da prendere.


 volte Internet Explorer succede lo stesso?
senti un po, un conto è dire che una determinata tecnolgia sia bacata,
un'altra è buttarla su discorsi da bar; c'è un bug? bene, quale? come si
riproduce?
il fatalismo non porta da nessuna parte e nemmeno il fare di tutta un'erba
un fascio;
la deallocazione automatica della memoria di COM non funziona? bene, quando?
in che situazione? hai esempi concreti?
senza offesa ma le considerazioni da te espresse non mi sono di alcuna
utilità... se dovessi seguire la tua filosofia (tutto è bacato, tutto
crasha...) mi troverei a proteggere con un  On Error anche istruzioni del
tipo A$ = "Pippo"
è innegabilmente vero che in situazioni particolari una assegnazione come
quella può causare un out of memory, ma alzi la mano chi si "diverte" a
proteggere il suo codice anche da simili eventualità ;))
ciao

 ha scritto nel messaggio
news:9ihpt8$j67u3$1...@ID-92828.news.dfncis.de...
[snip]
Bello questo thread, peccato averlo visto solo adesso.
Senza entrare nel merito, dato che già avete sviscerato di tutto di +,  devo
dare ragione a Gianni e Fibia.
Sono d'accordo con te sul piano "filosofico", ma la realtà è un'altra, e lo
ammette anche Ms, quando raccomanda di settare a nothing esplicitamente gli
oggetti per deallocarli...
Alla peggio, dovrebbero pensarci i processi di garbage, ma...
In fondo, senza pretendere di trappare la A$="pippo", non si chiede poi quel
grande sforzo, no?  :-)
ciao
ugo