Должен ли компилятор намекать / предупреждать при передаче экземпляров объекта напрямую в качестве параметров константного интерфейса?

Должен ли компилятор намекать / предупреждать при передаче нового экземпляра объекта методу, имеющему параметр константного интерфейса интерфейса, который реализует класс объекта?

Изменить ]: Образец, конечно, прост, чтобы проиллюстрировать проблему. Но в реальной жизни все становится намного сложнее: что, если создание и использование находятся в коде, который находится далеко друг от друга (разные единицы, разные классы, разные проекты)? Что, если его поддерживают разные люди? Что, если неконстантный параметр становится константным, и не весь вызывающий код можно проверить (потому что лицо, изменяющее код, не имеет доступа ко всему вызывающему коду)?

Код, как показано ниже, дает сбой, и это очень сложно чтобы найти причину.

Сначала журнал:

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

Затем код, который преждевременно освобождает экземпляр объекта, реализующий интерфейс:

//{$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 проявит себя во втором вызове Dump (Reference); . Причина в том, что счетчик ссылок базового объекта, предоставляющего ссылку, уже равен нулю, поэтому базовый объект уже уничтожен.

Несколько примечаний по коду подсчета ссылок, вставленному или опущенному компилятором:

• параметры, не отмеченные const (как в дампе процедуры (Ссылка: IInterface); ) получить неявные блоки try / finally для выполнения подсчета ссылок.
• параметры, помеченные const (например, в процедуре LeakCrash (const Ссылка: IInterface); ) не получают никакого кода подсчета ссылок
• , передающего результат создания экземпляра объекта (например, LeakCrash (TMyInterfacedObject.Create ()); ) не генерирует никакого кода подсчета ссылок

Само по себе все вышеперечисленное поведение компилятора очень логично,но вместе они могут вызвать EInvalidPointer.
EInvalidPointer проявляется только в очень узком шаблоне использования.
Шаблон легко распознать компилятор, но очень сложно отладить или найти причину, когда вы попали в ловушку.
Обходной путь довольно прост: кэшируйте результат TMyInterfacedObject.Create () в промежуточной переменной, а затем передайте его в LeakCrash () .

Должен ли компилятор намекать или предупреждать вас об этом шаблоне использования?

Наконец, код, который я использовал для отслеживания всех вызовов _AddRef / _Release / etcetera:

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