delphi - ¿Debería el compilador insinuar/advertir al pasar instancias de objeto directamente como parámetros de interfaz const?

interface parameters

Question

¿El compilador debería advertir / advertir al pasar una nueva instancia de un objeto a un método que tenga un parámetro de interfaz const de una interfaz que implemente la clase del objeto?

Edición : la muestra por supuesto es simple para ilustrar el problema. Pero en la vida real se vuelve mucho más complejo: ¿y si la creación y el uso están en un código que está muy alejado (unidades diferentes, clases diferentes, proyectos diferentes)? ¿Qué pasa si es mantenido por diferentes personas? ¿Qué pasa si un parámetro no const se convierte en uno const y no se puede verificar todo el código de llamada (porque la persona que cambia el código no tiene acceso a todos los códigos de llamada)?

Codifique los siguientes bloqueos, y es muy difícil encontrar la causa.

Primero el registro:

1.Run begin
1.RunLeakCrash
2.RunLeakCrash begin
NewInstance 1
AfterConstruction 0
3.LeakCrash begin
_AddRef 1
4.Dump begin
4.Dump Reference=10394576
4.Dump end
_Release 0
_Release Destroy
BeforeDestruction 0
3.LeakCrash Reference got destroyed if it had a RefCount of 1 upon entry, so now it can be unsafe to access it
_AddRef 1
4.Dump begin
4.Dump Reference=10394576
4.Dump end
_Release 0
_Release Destroy
BeforeDestruction 0
3.LeakCrash end with exception
1.Run end
EInvalidPointer: Invalid pointer operation

Luego, el código que libera prematuramente la instancia del objeto implementando una interfaz:

//{$define all}
program InterfaceConstParmetersAndPrematureFreeingProject;
{$APPTYPE CONSOLE}
uses
SysUtils,
Windows,
MyInterfacedObjectUnit in ''../src/MyInterfacedObjectUnit.pas'';
procedure Dump(Reference: IInterface);
begin
Writeln('' 4.Dump begin'');
Writeln('' 4.Dump Reference='', Integer(PChar(Reference)));
Writeln('' 4.Dump end'');
end;
procedure LeakCrash(const Reference: IInterface);
begin
Writeln('' 3.LeakCrash begin'');
try
Dump(Reference); // now we leak because the caller does not keep a reference to us
Writeln('' 3.LeakCrash Reference got destroyed if it had a RefCount of 1 upon entry, so now it can be unsafe to access it'');
Dump(Reference); // we might crash here
except
begin
Writeln('' 3.LeakCrash end with exception'');
raise;
end;
end;
Writeln('' 3.LeakCrash end'');
end;
procedure RunLeakCrash;
begin
Writeln('' 2.RunLeakCrash begin'');
LeakCrash(TMyInterfacedObject.Create());
Writeln('' 2.RunLeakCrash end'');
end;
procedure Run();
begin
try
Writeln(''1.Run begin'');
Writeln('''');
Writeln(''1.RunLeakCrash'');
RunLeakCrash();
finally
Writeln('''');
Writeln(''1.Run end'');
end;
end;
begin
try
Run();
except
on E: Exception do
Writeln(E.ClassName, '': '', E.Message);
end;
Readln;
end.

EInvalidPointer se manifestará dentro de la segunda llamada a Dump(Reference); . El motivo es que el recuento de referencias del objeto subyacente que expone la referencia ya es cero, por lo que el objeto subyacente ya se destruyó.

Algunas notas sobre el código de conteo de referencia insertado u omitido por el compilador:

• parámetros no marcados con const (como en el procedure Dump(Reference: IInterface); ) obtener implícito los bloques try / finally para realizar el recuento de referencias.
• los parámetros marcados con const (como en el procedure LeakCrash(const Reference: IInterface); ) no obtienen ningún código de conteo de referencia
• pasar el resultado de una creación de instancia de objeto (como LeakCrash(TMyInterfacedObject.Create()); ) no genera ningún código de recuento de referencia

Solo todos los comportamientos del compilador anteriores son muy lógicos, pero combinados pueden causar un EInvalidPointer.
EInvalidPointer se manifiesta solo en un patrón de uso muy estrecho.
El patrón es fácil de reconocer por el compilador, pero es muy difícil depurarlo o encontrar la causa cuando lo atrapó.
La solución es bastante simple: almacena en caché el resultado de TMyInterfacedObject.Create() en una variable intermedia, y luego lo pasa a LeakCrash() .

¿El compilador debería advertirle sobre este patrón de uso?

Finalmente, el código que utilicé para rastrear todas las llamadas a _AddRef / _Release / etccetera:

unit MyInterfacedObjectUnit;
interface
type
// Adpoted copy of TInterfacedObject for debugging
TMyInterfacedObject = class(TObject, IInterface)
protected
FRefCount: Integer;
function QueryInterface(const IID: TGUID; out Obj): HResult; stdcall;
function _AddRef: Integer; stdcall;
function _Release: Integer; stdcall;
public
procedure AfterConstruction; override;
procedure BeforeDestruction; override;
class function NewInstance: TObject; override;
property RefCount: Integer read FRefCount;
end;
implementation
uses
Windows;
procedure TMyInterfacedObject.AfterConstruction;
begin
InterlockedDecrement(FRefCount);
Writeln('' AfterConstruction '', FRefCount);
end;
procedure TMyInterfacedObject.BeforeDestruction;
begin
Writeln('' BeforeDestruction '', FRefCount);
if RefCount <> 0 then
System.Error(reInvalidPtr);
end;
class function TMyInterfacedObject.NewInstance: TObject;
begin
Result := inherited NewInstance;
TMyInterfacedObject(Result).FRefCount := 1;
Writeln('' NewInstance '', TMyInterfacedObject(Result).FRefCount);
end;
function TMyInterfacedObject.QueryInterface(const IID: TGUID; out Obj): HResult;
begin
Writeln('' QueryInterface '', FRefCount);
if GetInterface(IID, Obj) then
Result := 0
else
Result := E_NOINTERFACE;
end;
function TMyInterfacedObject._AddRef: Integer;
begin
Result := InterlockedIncrement(FRefCount);
Writeln('' _AddRef '', FRefCount);
end;
function TMyInterfacedObject._Release: Integer;
begin
Result := InterlockedDecrement(FRefCount);
Writeln('' _Release '', FRefCount);
if Result = 0 then
begin
Writeln('' _Release Destroy'');
Destroy;
end;
end;
end.

--jeroen

Answer 1

Es un error. La conversión de la instancia a la referencia de la interfaz en RunLeakCrash debe ser una variable temporal, manteniéndola activa mientras dure RunLeakCrash.

Answer 2

Yo votaría por una advertencia, ya que incluso los desarrolladores experimentados podrían caer en esta trampa. Si alguien no quiere esa advertencia, se puede desactivar fácilmente, lo que significa que no hay cambios con respecto al comportamiento actual. Es algo así como advertencias a variables no inicializadas o algo así.

Otra solución a este problema podría ser un Assert(InterfaceParameter.RefCount > 0); implícito Assert(InterfaceParameter.RefCount > 0); para los parámetros de interfaz const. Probablemente solo se emita cuando las aserciones están activadas.

Answer 3

pasar el resultado de una creación de instancia de objeto (como LeakCrash (TMyInterfacedObject.Create ());) no genera ningún código de recuento de referencia

Arriba está el error del compilador. Debe crear una var oculta y disminuir el contador cuando el procedimiento existió