más buenas prácticas de programación

[roman]

Tal como dice Al. Es completamente seguro usar Free en nil. Ese es el objetivo de Free, que sea seguro usarlo. Y lo es porque nunca hay una llamada a nil.Destroy.

// Saludos

[roman]

A ver, borrón y cuenta nueva.

Creo que ya veo por donde va la preocupación de Donald. A él no le inquieta la llamada a Destroy, sino la misma llamada a nil.Free.

Pero creo que hay que recordar que un objeto no es un record. ¿Qué pasa cuando se llama nil.Free? El compilador genera esta llamada:

mov eax, [eax + ...]
call TObject.Free

Esto es, la función que se llama es TObject.Free que vive en algún lugar de la tabla de métodos de la clase (no el objeto) TObject. Aquí no hay problema entonces, porque TObject existe independientemente de sus instancias. Y a Free se le pasa el parámetro Self que menciona Al, que es la instancia a la que se le aplica el método. Y es ya Free el que protege la llamada al destructor.

// Saludos

[donald shimoda]

Empezado por roman

A ver, borrón y cuenta nueva.

Creo que ya veo por donde va la preocupación de Donald. A él no le inquieta la llamada a Destroy, sino la misma llamada a nil.Free.

Exacto.

Empezado por roman

Pero creo que hay que recordar que un objeto no es un record. ¿Qué pasa cuando se llama nil.Free? El compilador genera esta llamada:

mov eax, [eax + ...]
call TObject.Free

Esto es, la función que se llama es TObject.Free que vive en algún lugar de la tabla de métodos de la clase (no el objeto) TObject. Aquí no hay problema entonces, porque TObject existe independientemente de sus instancias. Y a Free se le pasa el parámetro Self que menciona Al, que es la instancia a la que se le aplica el método. Y es ya Free el que protege la llamada al destructor.

// Saludos

Tenes razón, aunque a simple vista parezca voladura.

Para agregar a la charla y enriquecerla , un post sobre los efectos colaterales de la forma en que esta implementado, sobre todo cuando usas tareas:

link

Saludos.

[olbeup]

Hola ???

Retomando la pregunta inicial.

Código Delphi [-]
function TForm1.GetStrings:TStrings;
var
  miLista: TStrings;
begin
  miLista := TStringList.Create;
  miLista.Add('uno');
  miLista.Add('dos');
  Result := miLista;
  FreeAndNil(MiLista); // Esta linea da un error EAccessViolation
end;
procedure TForm1.Button1Click(Sender: TObject);
begin
  memo1.Lines.Assign(GetStrings);
end;

Por que no haces esto:

Código Delphi [-]
function TForm1.GetStrings:TStrings;
begin
  Result := TStringList.Create;
  Result.Add('uno');
  Result.Add('dos');
end;

procedure TForm1.Button1Click(Sender: TObject);
begin
  memo1.Lines.Assign(GetStrings);
end;

Al salir de la función GetStrings, la variable se libera sola.

Un saludo

[[Lepe]]

Empezado por olbeup

Al salir de la función GetStrings, la variable se libera sola.

¿quien te ha dicho eso? ¿eh? que yo me entere

[Casimiro Noteví]

Empezado por olbeup

Al salir de la función GetStrings, la variable se libera sola.

Empezado por Lepe

¿quien te ha dicho eso? ¿eh? que yo me entere

Evidentemente, no, no se libera sola.

Creo que hay una regla simple para no equivocarse:
Si tú coges memoria --> tú tienes que liberarla cuando terminas
Si Delphi coge memoria --> Delphi la libera cuando termina.


No recuerdo si existe alguna excepción a la regla, como casi siempre

[[Lepe]]

Empezado por Casimiro Notevi

No recuerdo si existe alguna excepción a la regla, como casi siempre

¿_CopyObject?


(perdón).

Saludos