Newsgroup: it.comp.lang.delphi
Titolo: reinstanziare un oggetto senza liberarlo [delphi7]

Mi ï¿œ successa una cosa strana che portava strani comportamenti a una 
finestra. :-)
 
In una form ho un campo privato
 
private
   FObject:TMyObject;
 
che veniva instanziato nel create della form
 
procedure myform.FormCreate(Sender: TObject);
begin
   FObject := TMyObject.Create(Appplication);
   ...
 
poi in quando si fa una determinata operazione, la classe non so per 
quale motivo veniva reinstanziata sebbene era giï¿œ instaziata e 
praticamente poi succedevano delle cose assurde.
 
procedure myform.Print();
begin
   FObject := TMyObject.Create(Application);
 
a parte che secondo me ï¿œ sbagliato reinstanziare l'oggetto tuttavia 
magari prima si dovrebbe usare freeandnil? Altrimenti cosa succede?

Sarà che il lunedi' sono piu' ..zzzato del solito ma non ho capito...
 
Se hai 2 create, l'oggetto viene istanziato 2 volte, punto.
Se l'istanza la crei nella oncreate del form non ti serve crearla una 2a volta.
Se l'hai gia' creata e usi lo stesso membro per una nuova create senza farne prima la free, hai un memory leak.
 
A.
 

 magari prima si dovrebbe usare freeandnil? Altrimenti cosa succede?
 
Nella print reistanzi un'altra volta FObject, creando un memory leak.
Toglilo dal print, perchè viene già istanziato nell'OnCreate del form 
che lo contiente.
 
 
-- 
morde
Android
QT 4.7
Delphi (5,6,7.. expired)
Firebird Database
 

 Se l'hai gia' creata e usi lo stesso membro per una nuova create senza farne prima la free, hai un memory leak.
 
esatto ci sarebbe un memory leak, per� succedevano anche cose strane 
tipo il fastreport che dipendeva da un dataset presente in quella classe 
andava totalmente fuori di testa senza alcun motivo...  secondo me 
faceva casino con i registri di memoria. boh :D
 
cmq ora si crea solo nel create l'altra linea � stata commentata! lol

 che lo contiente.
 
si esatto infatti l'ho commentata, perï¿œ oltre al memoryleak c'era un 
report collegato a un dataset dentro quella classe che faceva casino, se 
era presente quella riga della re-instanziazione...
 
ps
probabilmente veniva fatto il re-create della classe perchï¿œ nel 
costruttore c'erano delle procedure di reset dei valori... boh

1) IL FATTO CHE *PUOI* NON VUOL DIRE CHE *DEVI*.
 
2) ISTANZIARE USANDO UN MEMBRO CHE PUNTA AD INSTANZA GIA' ESISTENTE PRIMA CHE ESSA SIA STATA LIBERATA E' **SBAGLIATO** SIA IN PRESENZA DI GC CHE IN SUA ASSENZA. E' UNA COSA DA NON FARE. 
 
A.
 

 E' **SBAGLIATO** SIA IN PRESENZA DI GC CHE IN SUA ASSENZA. E' UNA COSA DA NON FARE.
 
 
concordo non ha senso... purtroppo per� mi pareva di ricordare di aver 
visto del codice dove veniva fatto.  :-)
 
ciao
 
 
 
 

 2) ISTANZIARE USANDO UN MEMBRO CHE PUNTA AD INSTANZA GIA' ESISTENTE PRIMA CHE ESSA SIA STATA LIBERATA E' **SBAGLIATO** SIA IN PRESENZA DI GC CHE IN SUA ASSENZA. E' UNA COSA DA NON FARE. 
 
Mmm, in presenza di un GC mi pare non ci sia nulla di male né di sbagliato.
 
Quando non c'è un GC, è "sbagliato" ma non dal punto di vista della logica specifica del programma, ma solo per il fatto che perdendo il riferimento non si riesce a distruggere l'oggetto.
 
Se si lavora con interfacce, o magari il riferimento va in una variabile temporanea e l'oggetto è creato (e distrutto) altrove, non ci vedo nulla di male.
 
In breve, deve valere solo il principio per cui quello che si crea va rilasciato.
 
Ciao,
  Marco.
 
-- 
MARCO BREVEGLIERI
#Home: 
http://www.marco.breveglieri.name
 
#Blog: 
http://www.compilaquindiva.net
 

Quello che io non condivido è che:
 
1) in punto uso il membro privato per istanziare una classe 
Ok.
 
2) in un altro punto riutilizzo lo stesso membro per una nuova create
Sbagliato, salvo casi particolari
 
3) faccio quanto al punto 2 senza lanciare una free (o una dispose)
 
Il caso dell'op...
Nella oncreate di un form crei un istanza.
Hai la certezza che questa create viene fatta solo una volta.
Il form ha 15 metodi che usano il membro private.
Uno di questi metodi lo riutilizza per una nuova create.
 
Certo, se ho GC *magari* lui si accorge che stai facendo questa cosa e l'istanza esistente viene etichettata per una successiva pulizia.
E se non hai il gc hai un leak. Ok. Perfetto.
 
E negli altri 14 metodi come fai a essere certo che l'istanza è quella corretta che ti serve? Chi ti garantisce che gli altri 14 metodi funzioneranno come si deve anche con una istanza della classe?
 
Mi accorgo di non essere stato chiaro nel mio precedente post:
 
istanziare piu' volte un membro *con scope a livello di classe* è sbagliato perchè introduce instabilità e non dovrebbe essere fatto salvo che in casi particolari. In più, se non esiste un GC crei dei leak.
 
A.
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
Al solito, molto dipende da cosa devi fare
