Почему есть утечка памяти при использовании интерфейсов?

← →
Суслик © (2005-06-24 12:59) [0]

Есть два метода <code> procedure Dummy1(const aI: IInterface); begin   // некая операция с aI end; procedure Dummy2(aI: IInterface); begin   // некая операция с aI end; </code> При вызове Dummy1(TInterfaceObject.Create()) происходит утечка памяти т.к. не отрабатывает деструктор созданного объекта TInterfaceObject. При вызове Dummy2(TInterfaceObject.Create())  все ок - деструктор отрабатывает корректно. Это глюк delphi или мой?

← →
Digitman © (2005-06-24 13:03) [1]

> Это глюк delphi или мой? ни твой ни Делфи. это - ФИЧА (а не баг и не "глюк") при const aI: IЧегоТоТам инкремента интерф.ссылки НЕ происходит, а при < aI: IЧегоТоТам происходит

← →
Суслик © (2005-06-24 13:04) [2]

>  [1] Digitman ©   (24.06.05 13:03) Да это понятно, что фича (cpu я тоже смотреть умею). Только: 1. она нигде не описана 2. она изрядно гадит жизнь (

← →
Digitman © (2005-06-24 13:10) [3]

> она нигде не описана описана. в справке просто покопаться следует изрядно детальней ... ибо прямой ссылки нет ... > она изрядно гадит жизнь ой не ври) достаточно знать и понимать, что при передаче по const Делфи-компайлер НЕ ответственен за работу со сч-ком ссылок, в то время как во 2-м упомянутом варианте делфи-компайлер вставляет неявный код инкремента (и, если требуется, - декремента) упомянутого сч-ка интерфейсной ссылки попросту говоря, при const никаких неявных _addref, _release нет, в то время как в упомянутом ином случае они фигурируют (и вполне оправданно)

← →
default © (2005-06-24 13:21) [4]

Суслик ©   (24.06.05 13:04) [2] совершенно логично действует компилятор...

← →
Digitman © (2005-06-24 13:31) [5]

> Суслик а есть ведь еще вариант с var Intf: IМойИнтерфейс странно что ты не присовокупил  его к вопросу, ибо так же концептуален он

← →
Суслик © (2005-06-24 14:01) [6]

>  [5] Digitman ©   (24.06.05 13:31) такой вариант работает, есно я это проверил. В справке про const скорее всего это есть. Но ... читай дальше ---------- ... про логичность я бы не стал соглашаться. Т.к. фактически объект будучи созданным выходит из scope и если дельфи декларирует подсчет ссылок, то это ее дело уничтожать интрефейсы. А то, что я сам решил при передаче в метод не делать подсчет ссылок, это дельфи волновать вообще говоря мало должно - его задача обеспечивать live scope (если уж дельфи за это взялся).

← →
Digitman © (2005-06-24 14:15) [7]

> А то, что я сам решил при передаче в метод не делать подсчет > ссылок, это дельфи волновать вообще говоря мало должно совершенно верно. и именно поэтому ты в ДАННОМ случае передаешь свой интерфейс как параметр как const-параметр.... и компилятор при этом НЕ делает никаких неведомых тебе "телодвижений", т.е. все что ты понаписал - полностью прогнозируемо и подконтрольно тебе.

← →
Суслик © (2005-06-24 14:25) [8]

убрали бы они вообще нафиг из delphi подсчет ссылок, либо сделали нормальный garbage collection для интерфейсов. Все лучше было бы.

← →
Игорь Шевченко © (2005-06-24 14:29) [9]

Суслик ©   (24.06.05 14:25) [8] > либо сделали нормальный garbage collection для интерфейсов. Java или C# тебе в руки.

← →
Digitman © (2005-06-24 14:30) [10]

> Суслик ©   (24.06.05 14:25) [8] > бы они вообще нафиг из delphi подсчет ссылок, либо сделали > нормальный garbage collection для интерфейсов а вот тут ты уже начал ужасную чушь пороть) остановись, вникни, подумай над сабжем ! просмотри, к примеру, sconnect.pas ... остынь) ... все в этом плане закономерно и правильно ! )

← →
Digitman © (2005-06-24 14:32) [11]

> garbage collection для интерфейсов галиматья полная. что значит "сборка мусора для интерфейсов" ? НЕТ в списке существующих где-то там интерфейсов МУСОРА !

← →
Суслик © (2005-06-24 14:37) [12]

>  [11] Digitman ©   (24.06.05 14:32) ладно, давай без всяких там слов "галиматься" и пр. ------------ что будет здесь (ответь не пробуя, только честно)? <code>procedure e; begin   TInterfacedObject.Create(); end;</code>

← →
Digitman © (2005-06-24 14:48) [13]

> что будет здесь (ответь не пробуя, только честно)? конкретно здесь (т.е. при вызове ДАННОЙ процедуры откуда бы то ни было) будет утечка. тут и "пробовать" ничего не нужно - ты создал объект - экземпляр класса - потерял его адрес в памяти и уничтожить впоследствии, не имея адреса, разумеется не можешь. класс объекта в дан.случае совершенно неважен.

> [10] Digitman ©   (24.06.05 14:30) > просмотри, к примеру, sconnect.pas ... остынь) ... Ну да, они все делают через дополнительную локальную переменную: <code>function TDataBlockInterpreter.CallGetServerList: OleVariant; var  Flags: TVarFlags;  Data: IDataBlock; begin  Data := TDataBlock.Create as IDataBlock;  Data.Signature := CallSig or asGetAppServers;  Data := FSendDataBlock.Send(Data, True);  Result := ReadVariant(Flags, Data); end;</code> А, кстати, насчет того, что сборка мусора здесь ни при чем я с трудом могу с тобой согласиться. Зачем сделан посчет ссылок? (если не ошибаюсь в ++ его нет). Для того, чтобы было удобно. Но по факту получается так, что приходится помнить условия, при которых подсчет работает верно. Приведенный мной пример не единственный.

> [13] Digitman ©   (24.06.05 14:48) Ладно, закрыто. Просто запомню, что в данном случае нужно быть осторожней с const.

> Ну да, они все делают через дополнительную локальную переменную врешь) цитирую : <code>function TStreamedConnection.Send(const Data: IDataBlock; WaitForResult: Boolean): IDataBlock; var  Msg: TMsg;  Context: Integer; begin  if FSupportCallbacks then  begin    if not Assigned(FTransport) then Exit;    Data._AddRef;    PostThreadMessage(FTransport.ThreadID, THREAD_SENDSTREAM, Ord(WaitForResult),      Integer(Pointer(Data))); ...</code> > насчет того, что сборка мусора здесь ни при чем я с трудом > могу с тобой согласиться. Зачем сделан посчет ссылок? КАКОЕ отношение имеет механизм подсчета интерф.ссылок к т.н. "сборке мусора" ? изложи свое вИденье ... > Для того, чтобы было удобно Да, конечно. Мне, к примеру, неудобно, объявив в п/программе лок.переменную MyInterface типа ISomeInterface, заботиться о разрушении объекта, на который в ходе работы моей п/программы эта переменная ВОЗМОЖНО будет ссылаться. а возможно и НЕ будет. И я с полным пониманием происходящего доверяюсь компилятору, который в ДАННОМ случае вставит неявный код MyInterface := nil который , если ссылка <> nil, вызовет за меня, лентяя, метод ISomeInterface._Release, что приведет к разрушению интерф.объекта, если декремент сч-ка в этот момент приведет к нулевому его значению.

>  [17] Digitman ©   (24.06.05 15:03) Речь была про ВЫЗЫВАЮЩУЮ сторону. Я тебе ее процитировал. Т.е. если я не хочу, чтобы у меня в исходном примере были ошибки, то я должен делать также как они.

> Суслик ©   (24.06.05 15:06) [18] > Речь была про ВЫЗЫВАЮЩУЮ сторону ок. вызывающая сторона, зная прототип ф-ции с неким интерфейсным параметром (IUnknown или его произвольным наследником) в том или ином виде, обязана иметь четкое представление о том как поступит компилятор. в случае const или var компилятор НЕ генерирует неявного кода вызова методов _AddRef, _Release передаваемого интерф.объекта в противном случае компилятор генерирует неявный вызов _AddRef  в контексте "открывающего" п/программу оператора begin и неявный вызов _Release в контексте "закрывающего" п/программу оператора end

Почему есть утечка памяти при использовании интерфейсов? Найти похожие ветки