Здравствуйте, Serginio1, Вы писали:
LT>> Если оная ссылка так тебе дорога, сделай ее полем некоторого класса, LT>> который будет жить дольше формы. Или элементом списка, коллекции, LT>> если не устраивает Screen.Forms. Извещения сможешь получать LT>> через FreeNotification.
S> Все это я описывал выше только в упрощенном варианте. Чтобы получить FreeNotification владелец должен быть наследником от TComponent. И для этого городить целый класс, особенно когда контроль нужен на протяжении всей жизни программы.
Форма и есть TComponent.
S> Для каждой задачи нужно находить оптимальный вариант в том числе и обниливание ссылок переданных переменных, да и в обниливание глобальных переменных нет криминала. Это из разряда не использовать GoTo. Но это не значит, что пользуюсь этими методами. Везьде есть свои подводные камни.
Я не очень понимаю, причем здесь обнуление указателя, если тот же автор вопроса
спрашивает, как узнать, что "a" валидный указатель, если допускается b:= a; b.Free;
Ответ на этот вопрос уже был: "Никак".
Можно ответить по другому: "Не надо такого допускать (b:= a)"
Такого и не будет, если не плодить для этого глобальных переменных, которые
могут пережить этот самый объект.
S> Но опять же все зависит от задачи. И глобальные переменные тоже никто не упразднял.
Они существуют: Application, Screen, PopupMenuList и т.п.
Но это не повод для их приумножения.
Здравствуйте, akasoft, Вы писали:
A>Вот есть у нас класс Приложение. В одной программе таких классов больше одного быть не может. Или может? Надо заводить в каждой Форме по полю Application? Или же глобальная переменная?
Зачем ее заводить, если существует Application.
Если тебе не хватает в оном функциональности — можешь сделать TMyApplication.
A>Т.е. где грань разумного?
Не следует приумножать сущности сверх необходимого [Оккам]
A>Я ещё понимаю, если бы у TObject был метод class function Run, который бы получал управление при запуске. Override и дело с концом. Как в C#...
Здравствуйте, Leonid Troyanovsky, Вы писали:
LT> Зачем ее заводить, если существует Application. LT> Если тебе не хватает в оном функциональности — можешь сделать TMyApplication.
Т.е. мыслю я всё же корректно?
A>>Т.е. где грань разумного?
LT> Не следует приумножать сущности сверх необходимого [Оккам]
Ну это чужая цитата. А мне интересен твой подход и твоё мнение по данному вопросу. Ты же вот ратуешь за неиспользование глобальных переменных, почём зря. Ну и как определяешь для себя, когда можно? Как относишся к глобальным переменным, заведённым для нас Борланд: Application, Screen да и создаваемой переменной на каждый тип формы?
Моё вот мнение, что когда известно, что в задаче будет сиспользоваться только один экземпляр формы (класса, чего угодно), то можно и глобальной переменной обойтись. А если к этому синглтону ещё и обрщается от 2-х до 20-ти других классов, то это самый разумный выход. Чем поля-ссылки плодить, как если бы пользоваться только ООП.
Есть и другой способ — обмениваться сообщениями: а) через очередь Windows, б) через механизм Dispatch.
LT> У TApplication есть похожий метод
Здравствуйте, akasoft, Вы писали:
LT> Если тебе не хватает в оном функциональности — можешь сделать TMyApplication.
A>Т.е. мыслю я всё же корректно?
IMHO, у меня не было оснований в этом усомниться
LT> Не следует приумножать сущности сверх необходимого [Оккам]
A>Ну это чужая цитата. А мне интересен твой подход и твоё мнение по данному вопросу. Ты же вот ратуешь за неиспользование глобальных переменных, почём зря. Ну и как определяешь для себя, когда можно? Как относишся к глобальным переменным, заведённым для нас Борланд: Application, Screen да и создаваемой переменной на каждый тип формы?
Я привел цитату лишь потому, что вполне разделяю это убеждение.
По поводу Application, Screen, Printer и т.п., считаю допустимым злом.
А уж глобальные переменные для форм — эту борландовскую мысль считаю бредом.
Свои взгляды я пытался выразить в одной дискуссии, которая, правда
разползлась по нескольким тредам:
"Обойтись", видимо, правильный термин. Но, именно тогда, когда этих обращений
будет до 20 — значит — нужно более совершенное хранилище данных.
A>Есть и другой способ — обмениваться сообщениями: а) через очередь Windows, б) через механизм Dispatch.
Да, конечно, чтобы не плодить взаимозависимостей между модулями, лучше уж
сообщения, для оконных-то приложений.
A>С C# знаком? Почитай Эндрю Троелсена
, если есть возможность. По секрету скажу, это "наш" язык.
Знаком, так сказать, в теории. По книге Джефа Рихтера.
Наш язык — наше будущее. Хейлсберг, IMHO, не отсиживаться туда пошел.
A>Смысл моего высказывания в принципе в том, что в C# можно выбрать любой класс и назначить его запускающим. А в OP надо использовать begin end в .dpr.
Хоть в усеченном варианте, но такая возможность существует
Здравствуйте, Leonid Troyanovsky, Вы писали:
LT> Я не очень понимаю, причем здесь обнуление указателя, если тот же автор вопроса LT> спрашивает, как узнать, что "a" валидный указатель, если допускается b:= a; b.Free;
Узнать Валидный указатель или нет можно только если его обнилить при уничтожении.
Это легко достгается при добавлении ссылки в список класса например
TForm1.AddReference(Var f:Form1)
Begin
List.Add(@f)
end;
TForm1.RemoveReference(Var f:Form1)
Begin
List.Remove(list.IndexOF[@f])
end;
TForm1.Destroy
Var i:Integer;
Begin
For i:=0 to list.Count-1 Do
PCardinal(list[i])^:=0;
end;
LT> Ответ на этот вопрос уже был: "Никак". LT> Можно ответить по другому: "Не надо такого допускать (b:= a)"
Иногда нужно когда существуют перекрестные ссылки и не обязательно, что объект должен быть наследником от TComponent тем более когда отношения один ко многим. ИТД.
С уважением, Serginio.
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Serginio1, Вы писали:
S> Узнать Валидный указатель или нет можно только если его обнилить при уничтожении. S> Это легко достгается при добавлении ссылки в список класса например...
Похожий метод использует и Борланд во внутренностях своих модулей. По моему, с TThread так сделано. Или почти так...
Однако удобнее/изящнее вариант с интерфейсами, как Антон написал
D>>Вопрос такой, как определить, уничтожен ли объект на который указывает Form2? D>>Вопрос касается не только форм, но и любых наследников TObject иже с ними.
A>Обычно делается проверка на равенство nil, например
A>
A>if Assigned(Obj) then
A>begin
A> Obj.Free;
A> Obj := nil;
A>end;
A>
Если посмотреть как реализованы интерфейсы в Delphi (для каждого интерфейса объекта (не класса!!!) генерятся функции заглушки для передачи Self уже методам объекта, т.к. интерфейсы не привязаны к данным объекта, а только к VMT), то большого желания не возникает.
Лучше было бы определять как
TInterface = record
VMTCode:Pointer; // ссылка на таблицу ссылок методов
Data:Pointer; // Selfend;
Но у M$ своя политика.
Да иногда и вышепреведенный код вполне устраивает при определенных обстоятельствах особенно когда ссылаемому объекту очень захочется удалиться не взирая на ненулевой счеичик ссылок.
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Serginio1, Вы писали:
S> Но у M$ своя политика.
1. При чем тут политика МС? S> Да иногда и вышепреведенный код вполне устраивает при определенных обстоятельствах особенно когда ссылаемому объекту очень захочется удалиться не взирая на ненулевой счеичик ссылок.
Если эта скотина умрет, невзираян на ненулевой счетчик ссылок, то всем будет очень плохо. В частности, исходная задача (убедиться в валидности указателя) НЕ БУДЕТ решена.
... << RSDN@Home 1.1 beta 2 >>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, Serginio1, Вы писали:
S>> Но у M$ своя политика.
S>1. При чем тут политика МС?
Не знаю как передается ссылка на данные объекта в методы класса в С++ в Delphi в один из регистров.
А вот городить функции заглушки для каждого объекта не самый оптимальный способ. S>> Да иногда и вышепреведенный код вполне устраивает при определенных обстоятельствах особенно когда ссылаемому объекту очень захочется удалиться не взирая на ненулевой счеичик ссылок. S>Если эта скотина умрет, невзираян на ненулевой счетчик ссылок, то всем будет очень плохо. В частности, исходная задача (убедиться в валидности указателя) НЕ БУДЕТ решена.
А вот валидность указателей как раз и будет решена путем обниливания ее из деструктора.
Кстати очень хороший пример с потоками, но и с перекрестными ссылками такие вещи хороши. http://www.rsdn.ru/Forum/Message.aspx?mid=383899&only=1
А вы попробуйте применить исходный фрагмент в данной ситуации.
А потом перечитать Object Pascal Reference. И вспомнить про необходимость инициализировать локальные переменные.
Вообще, эксперимент — настоятельно рекомендованный шаг перед публикацией своих мнений. Особенно при попытках оспорить чужое мнение.
... << RSDN@Home 1.1 beta 2 >>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
