Dúvidas em liberar objetos da memória

10/08/2006

Pessoal


Assim como crio os objetos em run time, também devo liberar ele quando não precisar mais, ex:

SqlBuscaCad := TClientDataSet.Create(Self);

Linha de código
Linha de código
.
.

SqlBuscaCad.Free;

No exemplo citado está certo esta forma ??? Se eu não libero, cria uma espécie de lixo ??? É isso ???

Aguardo um retorno

Rogério


Rogeranalista

Respostas

10/08/2006

Michael

Olá Rogério!

Aplicações Win32 não são gerenciadas. Desta forma, é responsabilidade do desenvolvedor liberar os objetos que cria. No .NET ou Java, por exemplo, isso não é necessário, pois existe um processo chamado [b:4d0d9a87e6]Garbage Collector[/b:4d0d9a87e6] - Coletor de lixo - que desaloca a memória de objetos que não são mais usados.

É importante frisar tbm que teoricamente o sistema operacional libera a memória alocada de um aplicativo quando ele termina. Porém, é mais elegante e otimizado não deixar para ele essa responsabilidade. Note também que isso só ocorre qdo o programa termina. Durante a sua execução é vc quem deve gerenciar o uso da memória do software.

Em Delphi, quando se cria componentes, é possível usar o [b:4d0d9a87e6]mecanismo de owner[/b:4d0d9a87e6], para delegar para outro componente a responsabilidade de liberar os objetos marcados como sendo seus. Isso é feito no construtor das classes (herdadas de [b:4d0d9a87e6]TComponent[/b:4d0d9a87e6]). No exemplo que vc colocou, o [b:4d0d9a87e6]Owner [/b:4d0d9a87e6]informado é [b:4d0d9a87e6]Self[/b:4d0d9a87e6], ou seja, o componente dentro do contexto da chamada. Quando ele for destruído, o [b:4d0d9a87e6]ClientDataSet [/b:4d0d9a87e6]tbm será.

Então, não é estranho que vc, algumas linhas abaixo, destrua o objeto? A regra é: se é o tempo de vida do componente é determinado, então use [b:4d0d9a87e6]nil[/b:4d0d9a87e6] como owner. Se não, use [b:4d0d9a87e6]Self[/b:4d0d9a87e6], para componentes, e [b:4d0d9a87e6]Application[/b:4d0d9a87e6], para forms.

Se restar alguma dúvida, sugiro a leitura do meu artigo sobre criação de componentes em run-time, que foi publicado na edição 72 da revista ClubeDelphi.

[]´s


Responder Citar

10/08/2006

Rogeranalista

Ok, irei ler, mas obrigado pela ajuda


Responder Citar

11/08/2006

Dmalta

Roger,

Quando você for criar um objeto em código que não tenha [i:ae69d33cd6]Owner[/i:ae69d33cd6], como no caso que o Michael explicou, é muito importante usar um bloco de proteção [i:ae69d33cd6]try..finally[/i:ae69d33cd6].

Por exemplo:
List := TStringList.Create;
try
  { faz alguma coisa }
finally
  List.Free;
end;

Assim, se der algum problema entre o [i:ae69d33cd6]Create [/i:ae69d33cd6]e o [i:ae69d33cd6]Free[/i:ae69d33cd6] que gere uma exceção você garante que o objeto será liberado, não deixando vasamentos (´leaks´) de memória.

Um abraço


Responder Citar

11/08/2006

Rogeranalista

Colega

O que seria mesmo Owner ??? Pode dar um exemplo ???


Aguardo um retorno

Rogério


Responder Citar

12/08/2006

Raserafim

Owner é o pai do objeto, ou seja, o objeto owner será o responsável por liberar a memória do objeto filho quando o objeto pai for destruido.

ex:
...
var
  DataSet: TClientDataSet;
begin
  DataSet := TClientDataSet.Create(Self);
end;

neste exemplo o owner do DataSet (que é um componente ClientDataSet que está sendo criado em tempo de execução) é o Self (Self é o form ao qual vc está inserindo o componente ClientDataSet)

ou outro exemplo:
  Form2 := TForm2.Create(Form1);


com este código vc está criando (instanciando) o form2 e dizendo que o Owner dele será o Form1. e com isso ao destruir o form1, automaticamente será destrído o form2.

o delphi faz o seguinte quando cria automaticamente os forms, ele coloca como o Owner o Application, e com isso ao fechar a aplicação todos os forms também serão destrídos.


Responder Citar

14/08/2006

Michael

Owner é o pai do objeto, ou seja, o objeto owner será o responsável por liberar a memória do objeto filho quando o objeto pai for destruido.

É mais correto dizer que [b:51430a3dc0]Owner [/b:51430a3dc0]é o proprietário de componentes, e não de objetos. O conceito de pai tbm existe, e é obtido através da propriedade [b:51430a3dc0]Parent[/b:51430a3dc0], introduzida e contemplada nas classes [b:51430a3dc0]TControl [/b:51430a3dc0]e [b:51430a3dc0]TWinControl[/b:51430a3dc0].

[]´s


Responder Citar

14/08/2006

Siam

Mas [b:380fe11316]TWinControl[/b:380fe11316] não possui [b:380fe11316]Parent[/b:380fe11316]. Não seria: [b:380fe11316]Parent[/b:380fe11316] de [b:380fe11316]TControl[/b:380fe11316] retorna um [b:380fe11316]TWinControl[/b:380fe11316] ?


Responder Citar

14/08/2006

Marco Salles

o que o Michael , acredito eu , quis colocar com esta colocação foi a relação entre Agrupado e Agrupar.....Para que um componente poder ser agrupado ele precisa ser descendente da TControl e para poder agrupar outros controles ele deve derivar da TWinControl <apesar de isto so não ser suficiente>

siam escreveu: Mas TWinControl não possui Parent.


Não entendi...Com assim não possui... e o conceito de herança ???
ja que TWincontrol é descendente de TControl...

var meucontrole:TWincontrol; begin meucontrole.Parent:=OutroControle;


Compila normalmente....


Responder Citar

14/08/2006

Michael

[quote:71afc13e55=´Marcos Salles´]o que o Michael , acredito eu , quis colocar com esta colocação foi a relação entre Agrupado e Agrupar.....Para que um componente poder ser agrupado ele precisa ser descendente da TControl e para poder agrupar outros controles ele deve derivar da TWinControl <apesar de isto so não ser suficiente>[/quote:71afc13e55]
Perfeito [b:71afc13e55]Marcos Salles[/b:71afc13e55].

Componentes derivados de [b:71afc13e55]TControl [/b:71afc13e55]apenas podem ser filhos de outros. Para serem pais, devem descender de [b:71afc13e55]TWinControl[/b:71afc13e55]. Essa é a diferença do uso de [b:71afc13e55]Parent[/b:71afc13e55].

[]´s


Responder Citar

14/08/2006

Rogeranalista

Agradeço pela ajuda e as dicas

Ainda não testei se deu certo... Assim que eu fizer e testar avisarei no forum.





Rogério


Responder Citar