más buenas prácticas de programación

[ContraVeneno]

¿por qué no seguir el ejemplo que viene en la ayuda de delphi?
Es decir, en el ejemplo de la ayuda de delphi, la última línea dice:
MyList.Free
no utilizan FreeAndNil....
Así que esto no debería darte problemas:

Código Delphi [-]
...
 miLista := TStringList.Create; 
 miLista.Add('uno'); 
 miLista.Add('dos'); 
 Result := miLista;   
 MiLista.Free; 
...

Aunque me gusta más lo que propone Caro, digo, si ya tienes un stringlist, ¿para qué crear otro?

[donald shimoda]

Empezado por ContraVeneno

Así que esto no debería darte problemas:

Código Delphi [-]
...
 miLista := TStringList.Create; 
 miLista.Add('uno'); 
 miLista.Add('dos'); 
 Result := miLista;   
 MiLista.Free; 
...

Amigo, repites el error del pimer post. Freeandnil solo hace

Código Delphi [-]
if Assigned(x) then
  x.free;

Es decir valida que solo libera cuando esta creado. Es codigo seguro.

Lo que tu colocas da problemas porque sigues liberando un objeto que pretendes devolver.

Saludos.

[[Al González]]

¡Hola!

Empezado por donald shimoda

...Freeandnil solo hace

Código Delphi [-]
if Assigned(x) then
  x.free;

Es decir valida que solo libera cuando esta creado. Es codigo seguro...

Disculpa que te corrija Donald, pero eso no es lo que hace FreeAndNil. Linett ha dado una explicación más cierta; la variable objeto queda con un valor en blanco (Nil) tras su liberación con FreeAndNil. Es el propio método Free el que hace una validación de seguridad antes de llamar al destructor Destroy.

Como ya se dijo, es normal utilizar FreeAndNil con variables globales, y aunque también puede ser aplicado a variables locales, por lo general sólo utilizamos Free con éstas. En otras palabras, el uso de FreeAndNil se justifica cuando existe la posibilidad de que alguna parte del código intente hacer algo con la instancia de objeto apuntada por la variable después de haberse destruido dicha instancia.

Por otro lado, la solución propuesta por Linett al principio me parece la más adecuada. Cuando mucho haría falta una llamada al método Clear antes del primer Add.

Un abrazo sin destruir.

Al González.

[donald shimoda]

Empezado por Al González

¡Hola!

Disculpa que te corrija Donald, pero eso no es lo que hace FreeAndNil. Linett ha dado una explicación más cierta; la variable objeto queda con un valor en blanco (Nil) tras su liberación con FreeAndNil. Es el propio método Free el que hace una validación de seguridad antes de llamar al destructor Destroy.

Tenes absolutamente razón, lo escribí rápido y me olvide que en realidad soy yo el que hago siempre:

Código Delphi [-]
if Assigned(x) then
  FreeAndNil(x);

Esto segun Allen Bauer es un vicio horrendo de programación . Ahora si mirás el código delhi de FreeAndNil:

Código Delphi [-]
procedure FreeAndNil(var Obj);
var
  Temp: TObject;
begin
  Temp := TObject(Obj);
  Pointer(Obj) := nil;
  Temp.Free;
end;

Si obj = nil estas llamando a nil.free!!!! No jodamos, es inaceptable o muy arriesgado para mis pareceres. Aunque se enoje Allen Bauer , escucho argumentos en contra que me quiten el vicio.

Saludos

[roman]

Empezado por donald shimoda

Si obj = nil estas llamando a nil.free!!!! No jodamos, es inaceptable o muy arriesgado para mis pareceres.

Al contrario. Como comenta Al, es el código de Free (ojo, no el de FreeAndNil) el que verifica que la referencia no sea nil.

Código Delphi [-]
procedure TObject.Free;
begin
  if Self <> nil then
    Destroy;
end;

Justo por eso (y sólo por eso) es que siempre se recomienda usar Free en lugar de Destroy.

// Saludos

[donald shimoda]

Empezado por roman

Al contrario. Como comenta Al, es el código de Free (ojo, no el de FreeAndNil) el que verifica que la referencia no sea nil.

Al contrario de que? No dije lo contrario, mira mas abajo.

Código Delphi [-]procedure TObject.Free; begin if Self <> nil then Destroy; end;


Justo por eso (y sólo por eso) es que siempre se recomienda usar Free en lugar de Destroy.

// Saludos[/quote]

Y te parece segura una llamada como Nil.free ????

Este tema incluso esta referenciado en el blog de Allen Bauer, no todos estan convencidos de una u otra manera. Para mi entre código raro y código seguro : siempre seguro. Eso me permite que un servidor corra 24 horas sin un solo problema.

Saludos.

[[Al González]]

Empezado por donald shimoda

...Y te parece segura una llamada como Nil.free ????...

En Delphi es de lo más seguro, Donald.

Cuando el objeto es Nil y el método Free hace esta validación:

Código Delphi [-]
if Self <> nil then

,

está preguntando si Nil es diferente de Nil, en cuyo caso llama a Destroy. De lo contrario no hace absolutamente nada. Si Free fuese un método virtual o hiciera alguna otra cosa con la "improbable" instancia, entonces sí sería inadecuado usarlo en esos casos.

Self es un parámetro implícito que llevan todos los métodos y equivale al puntero en sí de la instancia en cuestión. Nil, cuando el puntero está en blanco. No hay absolutamente ningún problema.

¿Ya convencido?

[[Al González]]

Empezado por donald shimoda

Tenes absolutamente razón, lo escribí rápido y me olvide que en realidad soy yo el que hago siempre:

Código Delphi [-]
if Assigned(x) then
  FreeAndNil(x);

Esto segun Allen Bauer es un vicio horrendo de programación . Ahora si mirás el código delhi de FreeAndNil:

Código Delphi [-]
procedure FreeAndNil(var Obj);
var
  Temp: TObject;
begin
  Temp := TObject(Obj);
  Pointer(Obj) := nil;
  Temp.Free;
end;

Si obj = nil estas llamando a nil.free!!!! No jodamos, es inaceptable o muy arriesgado para mis pareceres. Aunque se enoje Allen Bauer , escucho argumentos en contra que me quiten el vicio.

Saludos

Un placer, Donald. Argumentos dados tal como los solicitó. Sólo que es una pena no conocer si te convencieron para erradicar ese vicio y, en caso contrario, las razones.

Una disculpa a elcigarra por las derivaciones que tuvo el hilo (al menos por lo que a mí me toca).

Saludos.

Al González.

[donald shimoda]

Empezado por Al González

Un placer, Donald. Argumentos dados tal como los solicitó. Sólo que es una pena no conocer si te convencieron para erradicar ese vicio y, en caso contrario, las razones.

Como le dije a Román estoy totalmente de acuerdo en sus explicaciones, se las agradezco, son correctas, que mas debo decir?

Si han sido suficientes para erradicar el vicio? Primera regla del programador es no toques código que funciona sin una buena razón. No veo una buena razón en revisar código viejo.

Para el código nuevo probaré, te cuento cuando tenga mis propias pruebas de uso.

Saludos.

[[Al González]]

Empezado por donald shimoda

...Para el código nuevo probaré, te cuento cuando tenga mis propias pruebas de uso...

Urbana respuesta, gracias. Y una disculpa si te hice sentir presionado, no era esa la intención. Cuando gustes te invito un trago en La Taberna.

[*Caro*]

Empezado por ContraVeneno

¿por qué no seguir el ejemplo que viene en la ayuda de delphi?
Es decir, en el ejemplo de la ayuda de delphi, la última línea dice:
MyList.Free

Te daría el mismo error amiguito, ya que se estaría liberando antes de hacerle el Assign a la Lines del Memo.

Por lo menos yo cuando libero un TStringList lo hago con FreeAndNil, porque, digamos que tengo un tStringList como variable global en mi Unit. Cuando libero con Free y en otro lugar hago esto:

Código Delphi [-]
 if Assigned(Lista) then
  //Si existe quiero obtener su contenido

Al no haberlo hecho con FreeAndNil habiendolo liberado antes me sale un accessViolation, por eso lo libero con FreeAndNil.

Saluditos

[ContraVeneno]

ya, me guíe por el ejemplo de Delphi, no me había fijado que era una función que tendría que regresar ese valor.

[[Lepe]]

Resumiendo:
Si vas a reutilizar una variable varias veces (crearla en memoria y liberarla) es mejor usar FreeAndNil.

Si sólo vas a crear y destruir la variable una vez, puedes usar variable.Free;

Saludos