delphi - reynosa - ¿Por qué no debería usar "si está asignado()" antes de acceder a los objetos?

delphi technologies mexico

Question

Esta pregunta es una continuación de un comentario particular de personas en stackoverflow que he visto algunas veces diferentes ahora. Yo, junto con el desarrollador que me enseñó Delphi, para mantener las cosas seguras, siempre he puesto una marca if assigned() antes de liberar objetos, y antes de hacer otras cosas. Sin embargo, ahora me dicen que no debería agregar este cheque. Me gustaría saber si existe alguna diferencia en cómo la aplicación se compila / ejecuta si hago esto, o si no afectará el resultado en absoluto ...

if assigned(SomeObject) then SomeObject.Free;

Digamos que tengo un formulario, y estoy creando un objeto de mapa de bits en el fondo sobre la creación del formulario, y liberándolo cuando termine con él. Ahora supongo que mi problema es que me acostumbré demasiado a poner esta marca en gran parte de mi código cuando intento acceder a objetos que podrían haber sido liberados en algún momento. Lo he estado usando incluso cuando no es necesario. Me gusta ser completo ...

unit Unit1;
interface
uses
Windows, Messages, SysUtils, Variants, Classes, Graphics, Controls, Forms,
Dialogs;
type
TForm1 = class(TForm)
procedure FormCreate(Sender: TObject);
procedure FormDestroy(Sender: TObject);
private
FBitmap: TBitmap;
public
function LoadBitmap(const Filename: String): Bool;
property Bitmap: TBitmap read FBitmap;
end;
var
Form1: TForm1;
implementation
{$R *.dfm}
procedure TForm1.FormCreate(Sender: TObject);
begin
FBitmap:= TBitmap.Create;
LoadBitmap(''C:/Some Sample Bitmap.bmp'');
end;
procedure TForm1.FormDestroy(Sender: TObject);
begin
if assigned(FBitmap) then begin //<-----
//Do some routine to close file
FBitmap.Free;
end;
end;
function TForm1.LoadBitmap(const Filename: String): Bool;
var
EM: String;
function CheckFile: Bool;
begin
Result:= False;
//Check validity of file, return True if valid bitmap, etc.
end;
begin
Result:= False;
EM:= '''';
if assigned(FBitmap) then begin //<-----
if FileExists(Filename) then begin
if CheckFile then begin
try
FBitmap.LoadFromFile(Filename);
except
on e: exception do begin
EM:= EM + ''Failure loading bitmap: '' + e.Message + #10;
end;
end;
end else begin
EM:= EM + ''Specified file is not a valid bitmap.'' + #10;
end;
end else begin
EM:= EM + ''Specified filename does not exist.'' + #10;
end;
end else begin
EM:= EM + ''Bitmap object is not assigned.'' + #10;
end;
if EM <> '''' then begin
raise Exception.Create(''Failed to load bitmap: '' + #10 + EM);
end;
end;
end.

Ahora digamos que estoy presentando un nuevo objeto de lista personalizado llamado TMyList de TMyListItem . Para cada elemento en esta lista, por supuesto tengo que crear / liberar cada objeto del artículo. Hay algunas formas diferentes de crear un elemento, así como algunas formas diferentes de destruir un elemento (Agregar / Eliminar es el más común). Estoy seguro de que es una muy buena práctica poner aquí esta protección ...

procedure TMyList.Delete(const Index: Integer);
var
I: TMyListItem;
begin
if (Index >= 0) and (Index < FItems.Count) then begin
I:= TMyListItem(FItems.Objects[Index]);
if assigned(I) then begin //<-----
if I <> nil then begin
I.DoSomethingBeforeFreeing(''Some Param'');
I.Free;
end;
end;
FItems.Delete(Index);
end else begin
raise Exception.Create(''My object index out of bounds (''+IntToStr(Index)+'')'');
end;
end;

En muchos escenarios, al menos espero que el objeto aún se cree antes de intentar liberarlo. Pero nunca se sabe qué deslizamientos pueden ocurrir en el futuro cuando un objeto se libera antes de lo previsto. Siempre he usado este cheque, pero ahora me dicen que no debería, y todavía no entiendo por qué.

EDITAR

Aquí hay un ejemplo para tratar de explicarte por qué tengo el hábito de hacer esto:

procedure TForm1.FormDestroy(Sender: TObject);
begin
SomeCreatedObject.Free;
if SomeCreatedObject = nil then
ShowMessage(''Object is nil'')
else
ShowMessage(''Object is not nil'');
end;

Mi punto es que if SomeCreatedObject <> nil no es lo mismo que if Assigned(SomeCreatedObject) porque después de liberar SomeCreatedObject , no se evalúa como nil . Por lo tanto, ambos controles deberían ser necesarios.

Answer 1

Esta es una pregunta muy amplia con muchos ángulos diferentes.

El significado de la función Assigned

Gran parte del código en su pregunta revela una comprensión incorrecta de la función Assigned . La documentation dice esto:

Prueba un puntero nulo (no asignado) o una variable de procedimiento.

Use Asignado para determinar si el puntero o procedimiento al que hace referencia P es nulo. P debe ser una referencia variable de un puntero o tipo de procedimiento. Asignado (P) corresponde a la prueba P <> nil para una variable de puntero, y @P <> nil para una variable de procedimiento.

Retornos asignados Falso si P es nulo, Verdadero en caso contrario.

Nota : Assigned no puede detectar un puntero colgante, es decir, uno que no es nulo pero que ya no apunta a datos válidos. Por ejemplo, en el ejemplo de código para Asignado, Asignado no detecta que P no es válido.

Los puntos clave a tomar de esto son:

1. Assigned es equivalente a probar <> nil .
2. Assigned no puede detectar si el puntero o la referencia del objeto es válido o no.

Lo que esto significa en el contexto de esta pregunta es que

if obj<>nil

y

if Assigned(obj)

son completamente intercambiables.

Prueba Assigned antes de llamar Free

La implementación de TObject.Free es muy especial.

procedure TObject.Free;
begin
if Self <> nil then
Destroy;
end;

Esto le permite llamar Free a una referencia de objeto que es nil y hacerlo no tiene ningún efecto. Por lo que vale, no tengo conocimiento de ningún otro lugar en el RTL / VCL donde se usa ese truco.

La razón por la que desea permitir que se llame a Free en una referencia de objeto nil proviene de la forma en que los constructores y los destructores operan en Delphi.

Cuando se genera una excepción en un constructor, se llama al destructor. Esto se hace con el fin de desasignar los recursos asignados en la parte del constructor que tuvo éxito. Si Free no se implementó como está, los destructores tendrían que verse así:

if obj1 <> nil then
obj1.Free;
if obj2 <> nil then
obj2.Free;
if obj3 <> nil then
obj3.Free;
....

La siguiente pieza del rompecabezas es que los constructores de Delphi inicializan la memoria de la instancia a cero . Esto significa que los campos de referencia de objetos no asignados son nil .

Pon todo esto junto y el código destructor ahora se convierte

obj1.Free;
obj2.Free;
obj3.Free;
....

Debe elegir la última opción porque es mucho más legible.

Hay un escenario donde necesita probar si la referencia está asignada en un destructor. Si necesita llamar a cualquier método en el objeto antes de destruirlo, entonces debe evitar la posibilidad de que sea nil . Entonces este código correría el riesgo de un AV si apareciera en un destructor:

FSettings.Save;
FSettings.Free;

En cambio, escribes

if Assigned(FSettings) then
begin
FSettings.Save;
FSettings.Free;
end;

Prueba Assigned fuera de un destructor

También hablas de escribir código defensivo fuera de un destructor. Por ejemplo:

constructor TMyObject.Create;
begin
inherited;
FSettings := TSettings.Create;
end;
destructor TMyObject.Destroy;
begin
FSettings.Free;
inherited;
end;
procedure TMyObject.Update;
begin
if Assigned(FSettings) then
FSettings.Update;
end;

En esta situación, tampoco es necesario probar Assigned en TMyObject.Update . La razón es que simplemente no puede llamar a TMyObject.Update menos que el constructor de TMyObject . Y si el constructor de TMyObject tuvo éxito, entonces usted está seguro de que se le asignó FSettings . Así que de nuevo haces que tu código sea mucho menos legible y más difícil de mantener al realizar llamadas espurias a Assigned .

Hay un escenario en el que debe escribir if Assigned y es allí donde la existencia del objeto en cuestión es opcional. Por ejemplo

constructor TMyObject.Create(UseLogging: Boolean);
begin
inherited Create;
if UseLogging then
FLogger := TLogger.Create;
end;
destructor TMyObject.Destroy;
begin
FLogger.Free;
inherited;
end;
procedure TMyObject.FlushLog;
begin
if Assigned(FLogger) then
FLogger.Flush;
end;

En este escenario, la clase admite dos modos de operación, con y sin registro. La decisión se toma en el momento de la construcción y cualquier método que se refiera al objeto de registro debe probar su existencia.

Esta forma no común de código hace que sea aún más importante que no utilice llamadas falsas a Assigned para objetos no opcionales. Cuando vea if Assigned(FLogger) en el código que debería ser una clara indicación de que la clase puede funcionar normalmente con FLogger no existe. Si rocías llamadas gratuitas a Assigned alrededor de tu código, entonces pierdes la capacidad de decir de un vistazo si un objeto siempre debería existir o no.

Answer 2

No estoy completamente seguro de eso, pero parece:

if assigned(object.owner) then object.free

funciona bien. En este ejemplo, sería

if assigned(FBitmap.owner) then FBitmap.free

Answer 3

Por qué no deberías llamar

if Assigned(SomeObject) then
SomeObject.Free;

Simplemente porque ejecutarías algo como esto

if Assigned(SomeObject) then
if Assigned(SomeObject) then
SomeObject.Destroy;

Si llama solo SomeObject.Free; entonces es solo

 if Assigned(SomeObject) then
SomeObject.Destroy;

Para su actualización, si tiene miedo de la referencia de la instancia del objeto, use FreeAndNil. Destruirá y desreferenciará tu objeto

FreeAndNil(SomeObject);

Es similar a si llamas

SomeObject.Free;
SomeObject := nil;

Answer 4

Free tiene alguna lógica especial: comprueba si Self es nil , y si es así, vuelve sin hacer nada, por lo que puedes llamar a X.Free forma X.Free incluso si X es nil . Esto es importante cuando escribes destructores: David tiene más detalles en su respuesta .

Puede ver el código fuente de forma Free para ver cómo funciona. No tengo a mano la fuente Delphi, pero es algo como esto:

procedure TObject.Free;
begin
if Self <> nil then
Destroy;
end;

O, si lo prefiere, podría considerarlo como el código equivalente usando documentation :

procedure TObject.Free;
begin
if Assigned(Self) then
Destroy;
end;

Puede escribir sus propios métodos que comprueben if Self <> nil , siempre que sean métodos de instancia estáticos (es decir, no virtual o dynamic ) (gracias a David Heffernan para el enlace de documentación). Pero en la biblioteca Delphi, Free es el único método que conozco que utiliza este truco.

Por lo tanto, no necesita verificar si la variable está Assigned antes de llamar a Free ; ya lo hace por ti. En realidad, esa es la razón por la cual la recomendación es llamar a Free lugar de llamar directamente a Destroy : si llamaste a Destroy en una referencia nil , obtendrías una infracción de acceso.