ссылки на классы

[brabusman]

Вот столкнулся с таким, если создать класс и назначить две ссылки на этот класс, а потом одну из них освободить методом free, то вторая ссылка будет ссылаться на уже освобождённую ячейку памяти. Метод Assigned по второй ссылке дает true.

Вопрос: Можно ли второй ссылке узнать правильно ли она ссылается?

procedure TForm1.Button1Click(Sender: TObject);
var Obj1,Obj2:TObject;
begin
  Obj1:=TObject.Create;
  Obj2:=Obj1;             
  Obj1.Free;
  Obj1:=nil;

  if Assigned(Obj2) then   //здесь будет true
             Obj2.Free;                //ошибка, так как попытка освободить 
                                           //память по неправильной ссылке
end;

Не хочется делать какой-то внешний контролирующий орган(класс), который сам будет проверять и освобождать. Предполагается что эти ссылки находятся совсем в разных местах и друг о друге ничего не знают.

[mss]

Для этого придуманы интерфейсы.
см. TInterfacedObject

[Sibedir]

2 mss
Интерфейсы придуманы не для этого.

2 brabusman
Я понимаю о чем вы говорите. Но поймите главное. Если в программе имеет место вариант, когда может идти обращение в уже уничтоженному объекту, то логика построена не верно.

Я понимаю, что не очень наглядно, но конкретно в вашем примере решение в том, что нужно использовать всего одну ссылку на экземпляр. В данном случае две попросту не нужны.

var Obj1:TMyObject;
begin
  Obj1:=TMyObject.Create;

  Obj.BlaBlaBla;

  Obj1.Free;
  Obj1:=nil;

  if Obj1 <> nil then
             Obj1.Free;
end;

Ну или так

procedure TForm1.Button1Click(Sender: TObject);
var Obj1,Obj2:TObject;
begin
  Obj1:=TObject.Create;
  Obj2:=Obj1;             
  Obj1.Free;
  Obj1:=nil;

  if Obj1 <> nil then
             Obj2.Free;
end;

Для пущей убедительности: Приведите конкретный пример использования двух ссылок на один экземпляр, когда нельзя определить, что экземпляр уничтожен.

Можно конечно и так извратнуться: http://www.programmersforum.ru/showthread.php?t=127365
Но лично я все-таки предпочел изменить логику

[mss]

Интерфейсы придуманы не для этого

Для чего бы они ни были придуманы, но механизм подсчета ссылок на объект - одна из ключевых функциональностей интерфейсных объектов.

И не надо нести ересь про "нужно использовать всего одну ссылку на экземпляр".
Сколько нужно - столько и можно использовать.
А разрушение объекта при этом следует возложить на реализацию IUnknown._Release.

[boawinciace]

тратататыы

[Sibedir]

И не надо нести ересь про "нужно использовать всего одну ссылку на экземпляр".

Согласен, не правильно выразился. Конечно, ссылок может быть и несколько. Но основная должна быть одна. Например, можно несколько компонентов на форме поместить в массив (дублирование ссылки) для более удобного доступа к ним. Но это, скажем так, второстепенные ссылки. Ч/з них можно обращаться к полям и методам компонентов. Но, если какие-то компоненты уничтожены, нужно обязательно обновить массив.

А разрушение объекта при этом следует возложить на реализацию IUnknown._Release.

mss, еще раз приведу пример с линиями чертежа. Вот смотри, есть Линия1 и есть Линия2. Одна из точек Линии2 привязана к центру Линии1. Т.е. хранит ссылку на экземпляр Линии1. Другими словами Линии1.Счетчик = 2. Если удалить Линию1 (Линия1 := nil), то она не удалится, так как счетчик станет = 1, а не 0. Т.е. пока не отвяжем Линию2, Линия1 будет болтаться в памяти.
Интерфейсы здесь не подойдут. Нужно просто правильно организовать систему взаимосвязей.
Про вариант ТС вообще молчу. Там не то что интерфейсы не нужны, там вообще пример изначально не логичный.

[mss]

Линия1 будет болтаться в памяти

И пусть себе "болтается".
Если она "болтается", значит она кому-то еще нужна.
А если она этому "кому-то" стала больше не нужна, то этот "кто-то" обязан обнилить интерфейсную ссылку. И объект-линия будет автоматически уничтожен, как только он станет более не нужен ни одному из этих "кто-то".

[Johnson]

Пересматривайте логику без всяких "если". Создание объекта с попированием ссылки на другой объект - по меньшей мере "дурной тон". Либо используйте один класс, либо создавайте два класса.

И освобождать объект лучше по

FreeAndNil(TObject);

[Sibedir]

И пусть себе "болтается".

"Ну и пусть себе" - плохая фраза для программиста

Если она "болтается", значит она кому-то еще нужна.

Да ни кому она не нужна. Когда уничтожается Линия1, точка Линии2 (которая привязывалась к Линии1) должна стать просто глобальной точкой в общей системе координат.

А если она этому "кому-то" стала больше не нужна, то этот "кто-то" обязан обнилить интерфейсную ссылку. И объект-линия будет автоматически уничтожен, как только он станет более не нужен ни одному из этих "кто-то".

OK. А как этот "кто-то" узнает, что ссылка больше не актуальна?

Короче, интерфейсы тут не нужны, а нужно при удалении объекта известить кого следует. А за тем, кого нужно известить, и должен следить программист (а не интерфейс).
ИМХО: На автомате тут не проедешь.

Сообщение от Johnson

Создание объекта с попированием ссылки на другой объект - по меньшей мере "дурной тон". Либо используйте один класс, либо создавайте два класса.

Поясни
( хе-хе, опять 25)

[brabusman]

Цель использовать две ссылки это граф. Есть вершины (назовём TNode) и связи между этими вершинами. Каждая вершина имеет массив входящих и исходящих связей (array of TLink).

При уничтожении всего графа, выполняется destroy для каждой вершины, а в этом destroy'e уничтожаются все связи по данной вершине.

Но удалив связь, вторая вершина с которой эта связь выла установлена не знает что связи больше нет.

Сейчас реализовал так, при удалении вершины TNode отправляется сообщение всем соседям "Удалите из своего списка эту связь, но не выполняйте Free", после этого сообщения для всех связей делается free.

Но как-то мудрёно и отлаживать плохо.