Array
(
)

Dúvidas em liberar objetos da memória

RogerAnalista
   - 10 ago 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

Michael
   - 10 ago 2006

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 Garbage Collector - 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 mecanismo de owner, para delegar para outro componente a responsabilidade de liberar os objetos marcados como sendo seus. Isso é feito no construtor das classes (herdadas de TComponent). No exemplo que vc colocou, o Owner informado é Self, ou seja, o componente dentro do contexto da chamada. Quando ele for destruído, o ClientDataSet 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 nil como owner. Se não, use Self, para componentes, e Application, 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

RogerAnalista
   - 10 ago 2006

Ok, irei ler, mas obrigado pela ajuda

dmalta
   - 11 ago 2006

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

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

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

RogerAnalista
   - 11 ago 2006

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

Aguardo um retorno
Rogério

raserafim
   - 12 ago 2006

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:
#Código

...
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:
#Código
  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.

Michael
   - 14 ago 2006


Citação:
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 Owner é o proprietário de componentes, e não de objetos. O conceito de pai tbm existe, e é obtido através da propriedade Parent, introduzida e contemplada nas classes TControl e TWinControl.
[]´s

siam
   - 14 ago 2006

Mas TWinControl não possui Parent. Não seria: Parent de TControl retorna um TWinControl ?

RogerAnalista
   - 14 ago 2006

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

Michael
   - 14 ago 2006


Citação:
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>

Perfeito Marcos Salles.
Componentes derivados de TControl apenas podem ser filhos de outros. Para serem pais, devem descender de TWinControl. Essa é a diferença do uso de Parent.
[]´s

Marco Salles
   - 14 ago 2006

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>
Citação:
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...
Citação:
var
meucontrole:TWincontrol;
begin
meucontrole.Parent:=OutroControle;
Compila normalmente....