Free vs FreeAndNil

[Tuğrul HELVACI]

(03-02-2018, Saat: 16:52)sadettinpolat Adlı Kullanıcıdan Alıntı: Tugrul abi , FreeAndNil kullaniyorum , kullanmaya da devam edecegim. Kullanmaya devam etmemin en buyuk nedeni de senin dedigin gibi programi programcidan korumak icin. 
Daha iyi oldugundan ya da olmasi gereken o oldugu icin degil  kendi hatami tolere etmek icin kullanmaya devam edecegim. 

var
  C : TObject;
begin
  C := TObject.Create;
  ...
  ...
  FreeAndNil( C );
  ...
  ...
  if Assigned( C ) then
    C.Birşey;
end;

Bu kod blogu benim de kullandigim bir blok ama yillardir kullandigimiz icin sanirim bize dogru geliyor oysaki gunluk hayatin akisina ters bir durum mevcut. Kodu bir de soyle yazalim belki daha iyi anlasilir.

begin
  ArabayiCalistir; //C := TObject.Create;
  ArabaninGazinaBas;
  ArabayiAVMyeSur;
  ArabayiDurdur;  //FreeAndNil( C );
  AVMyeGir;
  AVMDeGezDolasDur;
  AVMdenCik;
  Eger ArabaCalisiyorsa  //if Assigned( C ) then
    ArabaninGazinaBas;
end;

Arabanin calismadigini AVM den ciktigimizda zaten biliyoruz , gunluk hayatta boyle bir kontrol yapmiyoruz. AVM ' den cikinca arabayi once calistirip sonra gaza basiyoruz. 
Gunluk hayatta yapmadigimiz bir davranisi kod yazarken yapmis oluyoruz. Bu isin detaylarini artik bir araya geldigimizde konusuruz Tugrul abi



Edit: 

Bu da VCL kodundan alinmis bir bolum. FreeAndNil komutundan dolayi bu kodu yazan arkadas 25. ve 44. satirlarda biraz musrif davranmamis mi ?

function TAmazonQueueService.CreateQueue(const QueueName: string; out QueueURL: string;
                                        const DefaultVisibilityTimeout: Integer;
                                        ResponseInfo: TCloudResponseInfo): Boolean;
var
 Response: TCloudHTTP;
 QueryParams: TStringList;
 xml: string;
 xmlDoc: IXMLDocument;
 ResultNode, QueueNode: IXMLNode;
begin
 QueryParams := BuildQueryParameters('CreateQueue');

 QueryParams.Values['QueueName'] := QueueName;

 if DefaultVisibilityTimeout > -1 then
 begin
   QueryParams.Values['Attribute.1.Name'] := 'VisibilityTimeout';
   QueryParams.Values['Attribute.1.Value'] := IntToStr(DefaultVisibilityTimeout);
 end;

 Response := nil;
 try
   Response := IssueRequest(GetConnectionInfo.QueueURL, QueryParams, ResponseInfo, xml);
   Result := (Response <> nil) and (Response.ResponseCode = 200);
   FreeAndNil(Response);

   if Result and (xml <> EmptyStr) then
   begin
     //Parse XML and get QueueURL value
     xmlDoc := TXMLDocument.Create(nil);
     xmlDoc.LoadFromXML(XML);

     ResultNode := xmlDoc.DocumentElement.ChildNodes.FindNode(NODE_QUEUE_CREATE_RESULT);

     if (ResultNode <> nil) and (ResultNode.HasChildNodes) then
     begin
       QueueNode := ResultNode.ChildNodes.FindNode(NODE_QUEUE);
       if (QueueNode <> nil) and (QueueNode.IsTextElement) then
         QueueURL := QueueNode.Text;
     end;
   end;
 finally
   if Assigned(Response) then
     FreeAndNil(Response);
   FreeAndNil(QueryParams);
 end;
end;

Senin adına sevindim sevgili kardeşim, ben de FreeAndNil kullanılması gerektiğini ifade etmeye çalışıyordum zaten. Bahsettiğin örneğe gelince; (benzer bir örneği Bahadır bey'de vermiş) bu tarz örneklerde elbette Free ve FreeAndNil kullanmanın hiç bir manası ve farkı yok. Çünkü ilgili nesne instance'ı kodun ilerleyen bölgelerinde zaten kullanılmıyor. Ancak yine de tedbirli olmanın ne gibi bir sakıncası olabilir ? Örneğin 2 ay sonra ilgili kod bloğuna bir şeyler ekleme ihtiyacı hissedebilir programcı.

Herneyse, velhasıl ben güvenli kod için her daim FreeAndNil kullanıyorum ve kullanmaya da devam edeceğim. Bu bir disiplin meselesi. Bu nedenle; TAmazonQueueService.CreateQueue örneğin için ben 25.ci satırı aşağıdaki gibi yazardım:

    
  if Assigned(Response) then
      FreeAndNil(Response);

Neden ? Çünkü bir üst satırda,

Result := (Response <> nil) and (Response.ResponseCode = 200);

gibi bir kontrol var. Demek ki Response nil olabiliyor. (Gerçekten olup olamadığını derinlemesine incelemek lazım ama programcıya inanıyoruz şu aşamada). Eh Response nil olabildiğine göre; boş yere FreeAndNil çağırmaya gerek kalmasın diye if Assigned ile kontrol ederdim. (Bir zararı olur mu if Assigned ile kontrol etmez isem ? Olmaz. Neden olmaz ? Çünkü TObject.Destroy'un içinde Self <> nil kontrolü var.)

 Ama mantıken, nil olan bir nesne instance'ı üzerinden metod çağrımı yapmak hatalı olacağı için, if Assigned kontrolünü her halükarda koyardım. Sizler ister buna zaman kaybı deyin isterse başka bir isim verin; ben kontrollü ve disiplinli olmayı seviyorum. Delphi'ciler TObject.Free içinde Self <> nil kontrolü koymamış dahi olsaydı, benim kontrollü kod yazmamdan ötürü bir AV hatası almayacaktım ben zaten.

 Free ile FreeAndNil arasında kaybedeceğiniz micro saniye'nin kaybedeceğiniz diğer unsurların yanında esamesi bile okunmaz diye düşünüyorum.

Senin AVM örneğin için ise; şunu söyleyebilirim:

Varsayalım ki, arabayı park eden kişinin bir rahatsızlıktan ötürü limitli bir hafızası var. Arabayı park ettiği yere geldiğinde arabanın çalışıp çalışmadığını hatırlayamıyor olsun ilgili kişi. Bu durumda, arabanın çalışıp çalışmadığını nasıl anlar ?

 Amma da soru ha diyeceksiniz sanırım. Bir bakışta çalışan araba ile çalışmayan araba bir çok şekilde tespit edilebilir. Evet doğru, haklısınız ama "insan beyni için" tespit edilebilir. Bilgisayarın tespiti için ise başka şeyler gerekir. Örneğin instance pointer'ın nil'e setlenmesi ve Assigned ile kontrol edilmesi gibi

[canbir]

Öncelikle bu faydalı konuya dahil olan ve bilgilerini paylaşan herkese teşekkür ediyorum.
Hafıza kaçağı olduğunu tespit ettiğim bir programımda, sorunun çok fazla kullanılan json okuma fonksiyonumdan kaynaklandığını tespit ettim. Fonksiyon sonundaki free metotlarını FreeAndNil ile değiştirdiğimde hafıza kaçağı sorunum kalmadı. Bu konuyu da "free etmek yetmiyor mu, neden bir ne nill yapmak gerekiyor?" diye düşünüp bunu araştırdığım için görmüş oldum.
Demek ki bazen free etmek yetmiyor. Tuğrul Beyin açıklamaları kafama yattığından, bundan sonra free yerine FreeAndNil kullanacağım.

[Halil Han BADEM]

Büyüyünce öğrendim ki gerekli durumlarda kullanılması gerekir.

[sadettinpolat]

rep puanini verdim ama nil hafiza kacagina neden olmaz. Tanimladiginiz bir nesneye ilklendirme yapmazsaniz yani nesneyi nile eşitlemezseniz sonradan yapacağınız nesne geçerli bir nesne mi değil mi kontrollerinde sıkıntı yaşar ve bunun sonucunda bazı istenmeyen olaylara davetiye çıkartmış olursunuz.

[Halil Han BADEM]

(27-05-2018, Saat: 01:38)sadettinpolat Adlı Kullanıcıdan Alıntı: rep puanini verdim ama nil hafiza kacagina neden olmaz. Tanimladiginiz bir nesneye ilklendirme yapmazsaniz yani nesneyi nile eşitlemezseniz sonradan yapacağınız nesne geçerli bir nesne mi değil mi kontrollerinde sıkıntı yaşar ve bunun sonucunda bazı istenmeyen olaylara davetiye çıkartmış olursunuz.

Nil hafiza kacagina sebep olur demedim. Nil kullanılmazsa hafıza kaçağı oluşabilir. Bu yüzden nil terimini bir şarta bağlamadim.

[edo]

(26-05-2018, Saat: 18:57)canbir Adlı Kullanıcıdan Alıntı: Öncelikle bu faydalı konuya dahil olan ve bilgilerini paylaşan herkese teşekkür ediyorum.
Hafıza kaçağı olduğunu tespit ettiğim bir programımda, sorunun çok fazla kullanılan json okuma fonksiyonumdan kaynaklandığını tespit ettim. Fonksiyon sonundaki free metotlarını FreeAndNil ile değiştirdiğimde hafıza kaçağı sorunum kalmadı. Bu konuyu da "free etmek yetmiyor mu, neden bir ne nill yapmak gerekiyor?" diye düşünüp bunu araştırdığım için görmüş oldum.
Demek ki bazen free etmek yetmiyor. Tuğrul Beyin açıklamaları kafama yattığından, bundan sonra free yerine FreeAndNil kullanacağım.

Bu konuyla doğrudan ilintili değil ama kısaca belirtmeden geçmek istemedim. 10.2 Tokyo verisyonundan önceki Rest objelerinde link deki gibi bir kaçak sebebi vardı. Bu işlem 10.2 Tokyo'da düzeltilmiş. Sorun yaşayanlar aşağıdaki atamayı deneyebilirler: 

RestClient.FallbackCharsetEncoding := '';