Есть ли будущее у DELPHI?

Цитата MyNameIsIgor @ 09.01.14, 10:04

как вообще можно вызвать метод уже уничтоженного объекта?

А где вызываются методы уничтоженного объекта? И в какой момент объект уничтожен?

Цитата --Ins-- @ 09.01.14, 10:30

А где вызываются методы уничтоженного объекта?

В контексте C++ так было бы, если бы работал полиморфизм в деструкторах.

Цитата --Ins-- @ 09.01.14, 10:30

И в какой момент объект уничтожен?

Когда отработал его деструктор.

Цитата OpenGL @ 09.01.14, 10:07

Создание и удаление объекта - дело исключительно этого объекта, а не потомков объекта этого класса.

Ага, интимное Полиморфное конструирование удобно и совершенно безопасно при правильном использовании. Но мне не интересно спорить на эту тему по десятому разу Давайте лучше про FreeAndNil если кому-то есть что добавить

Добавлено 09.01.14, 10:32

Цитата MyNameIsIgor @ 09.01.14, 10:31

Когда отработал его деструктор.

А, ну, когда отработал деструктор никакие методы этого объекта и не вызываются. Проблемы с FreeAndNil как раз из-за того возможны, что деструктор еще не отработал, а ссылка уже занулена

Сообщение отредактировано: --Ins-- - 09.01.14, 10:33

Цитата --Ins-- @ 09.01.14, 10:30

А где вызываются методы уничтоженного объекта?

В деструкторе наследника, не? У вас же там:

Цитата

В Дельфи полиморфизм на уровне конструирования и уничтожения - нормальная практика

Цитата --Ins-- @ 09.01.14, 10:30

И в какой момент объект уничтожен?

Так после отработки деструктора - объект уничтожен. А как в делфи при наличии полиморфизма? После вызова дестркутора объект еще живой, ага ?

Цитата Wound @ 09.01.14, 10:33

А как в делфи при наличии полиморфизма? После вызова дестркутора объект еще живой, ага ?

Агонизирует FreeAndNil его добивает

Добавлено 09.01.14, 10:36

Цитата --Ins-- @ 09.01.14, 10:31

Проблемы с FreeAndNil как раз из-за того возможны, что деструктор еще не отработал

Так нет же - деструктор потомка уже отработал.

Цитата --Ins-- @ 09.01.14, 10:31

Полиморфное конструирование удобно и совершенно безопасно при правильном использовании.

Я верю в это Я скорей не вижу в нем необходимости.

Цитата --Ins-- @ 09.01.14, 10:31

Но мне не интересно спорить на эту тему по десятому разу

Печально В предыдущих итерациях я не участвовал.

Цитата --Ins-- @ 09.01.14, 10:31

Проблемы с FreeAndNil как раз из-за того возможны, что деструктор еще не отработал, а ссылка уже занулена

Ага, так его судя по всему и предлагают пихать бездумно и везде, именно затем что деструктор еще не отработал, а объект уже удален и не занулен Рекурсия прям...

Цитата OpenGL @ 09.01.14, 10:36

Печально В предыдущих итерациях я не участвовал.

Ну, давайте, теперь ваша очередь - а мы посмотрим

Цитата Wound @ 09.01.14, 10:33

После вызова дестркутора объект еще живой, ага ?

Нужно понимать что такое в дельфи вызов деструктора, равно как и вызов конструктора. Деструктор и конструктор - не обычные методы, когда пишешь их вызов - работает магия компилятора, это не равносильно вызову обычного метода. Для клиентского кода Create и Destroy именно работают как конструктор и деструктор - выделяют/освобождают память, проводят инициализацию VMT и т.д, притом что их фактическое тело может быть пустым. Но когда мы к примеру пишем inherited Destroy в деструкторе потомка этот вызов никакую память под объект предка не освободит - это просто вызов кода деинициализации. На момент после этого вызова объект не уничтожен и destroy просто фактически обычный метод. Объект будет существовать до тех пор, пока вся цепочка не отработает. Так что утверждение, что на момент выполнения Destroy потомка предок уничтожен - неверно

Добавлено 09.01.14, 10:44

Цитата OpenGL @ 09.01.14, 10:36

Я скорей не вижу в нем необходимости.

А необходимости нет, впрочем как и вообще в полиморфизме Без него обойтись можно. Просто это удобная (порой) альтернатива

Добавлено 09.01.14, 10:45

Цитата Wound @ 09.01.14, 10:38

Ага, так его судя по всему и предлагают пихать бездумно и везде

Я вообще не понимаю мотивацию тех, кто предлагает его бездумно пихать везде. Если че, Борландовцы, когда придумывали дельфи, не предлагали, да и сейчас официально никто не предлагает. Есть чье-то сугубо личное спорное мнение на этот счет, не более того. Free предлагают писать вместо Destroy бездумно везде, но это то как раз понятно

Сообщение отредактировано: --Ins-- - 09.01.14, 10:46

Цитата --Ins-- @ 09.01.14, 10:43

Если че, Борландовцы, когда придумывали дельфи, не предлагали, да и сейчас официально никто не предлагают.

Зачем оно тогда вообще есть в стандартной библиотеке?

Цитата --Ins-- @ 09.01.14, 10:43

На момент после этого вызова объект не уничтожен и destroy просто фактически обычный метод. Объект будет существовать до тех пор, пока вся цепочка не отработает. Так что утверждение, что на момент выполнения Destroy потомка предок уничтожен - неверно

Формально - да. Т. е. объект "физически" ещё существует. Но вот существует ли он логически? Ведь с точки зрения логики весь код деинициализации уже выполнен. То, что память ещё не освобождена - это лишь формальность. А коли деинициализация уже произошла, то пользоваться таким объектом (с точки зрения логики) - смерти подобно. Точнее, эммм..., очень рискованно. Нет? И именно наличие такого функционала приводит к тому, что разработчиком приходится придумывать мозговыносящие инварианты, следить за их соблюдением, дёргать FreeAndNil, надеяться на то, что разработчики используемых компонент - в достаточной степени пряморукие. Вот оно вот так надо?

Цитата --Ins-- @ 09.01.14, 10:43

Так что утверждение, что на момент выполнения Destroy потомка предок уничтожен - неверно

А какой толк от этого потомка предка? Он же уже деинициализирован, отсюда могут быть скрытые ошибки, не зря же вы там в деструкторе на Nil проверяете все. Вот какой смысл мешать порядок вызова деинициализаторов?

Цитата korvin @ 09.01.14, 10:50

Зачем оно тогда вообще есть в стандартной библиотеке?

Хз. Наверное в самом деле как ремень безопасности для тех, у кого руки растут не из того места. Я им никогда не пользуюсь

Добавлено 09.01.14, 10:56

Цитата Flex Ferrum @ 09.01.14, 10:51

И именно наличие такого функционала приводит к тому, что разработчиком приходится придумывать мозговыносящие инварианты, следить за их соблюдением, дёргать FreeAndNil, надеяться на то, что разработчики используемых компонент - в достаточной степени пряморукие. Вот оно вот так надо?

Не приходится Я выше писал, FreeAndNil не нужен в нормальном коде, причем полиморфизм на этапе конструирования/деконструирования вполне может присутствовать. Но FreeAndNil все равно не нужен Единственное что может (и да, бывает) понадобится при таком подходе - это вставлять вызов конструктора/деструктора предка в произвольное место. Дельфи технически это тоже позволяет. И эта возможность при соблюдении некоторых простых правил делает вызовы виртуальных методов из конструктора/деструктора полностью безопасным. Хотя можно с этим и напортачить да, но это вопрос исключительно прямоты рук

Цитата --Ins-- @ 09.01.14, 10:43

Так что утверждение, что на момент выполнения Destroy потомка предок уничтожен - неверно

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

Цитата --Ins-- @ 09.01.14, 10:51

Хз. Наверное в самом деле как ремень безопасности для тех, у кого руки растут не из того места. Я им никогда не пользуюсь

Э-э... А в чем безопасность? Разве после вызова деструктора объект не должен и так становиться nil?