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

Цитата --Ins-- @ 09.01.14, 11:28

Я для нотификации об уничтожении объекта использую нотификацию в виде вызовов методов заинтересованных объектов

Какие красивые подпорки для соблюдения инвариантов в условиях дикой природы распоясавшегося полиморфизма

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

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

Цитата --Ins-- @ 09.01.14, 11:28

Чему равно b? Почему оно тоже должно стать 0? Оно так и останется 5

Ты меня давай не путай, у вас в делфях ссылочная семантика, соответственно в примере корвина - хранят ссылки на объекты, а не значения как в С++. На Nil то ты их сравниваешь, интересно как, если это полноценные объекты?

Цитата trainer @ 09.01.14, 11:31

Тогда зачем проверки на nil в конструкторах/деструкторах, если это не индикатор?

Ты разницу между "не создан" и "уничтожен" понимаешь?

Цитата --Ins-- @ 09.01.14, 11:20

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

По-моему это накладней и привносит больше возможностей отстрелить кому-нибудь ногу или еще чего.

Цитата Wound @ 09.01.14, 11:32

Ты меня давай не путай, у вас в делфях ссылочная семантика, соответственно в примере корвина - хранят ссылки на объекты, а не значения как в С++. На Nil то ты их сравниваешь, интересно как, если это полноценные объекты?

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

Добавлено 09.01.14, 11:40

Цитата korvin @ 09.01.14, 11:33

По-моему это накладней и привносит больше возможностей отстрелить кому-нибудь ногу или еще чего.

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

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

Цитата --Ins-- @ 09.01.14, 11:34

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

Подожди. Я запутался.

Добавлено 09.01.14, 11:41
Все я понял. Там же FreeAndNill зануляет только переданую переменную. Ну блин у вас и трешняк...

Цитата Wound @ 09.01.14, 11:41

Ну блин у вас и трешняк...

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

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

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

А я переучаствовал

Цитата --Ins-- @ 09.01.14, 11:33

Ты разницу между "не создан" и "уничтожен" понимаешь?

У нас вроде бы нет кладбищ объектов с памятниками "TObject'у от благодарных потомков", поэтому чем отличается не созданный от уничтоженного - не понимаю. И то и другое - биомасса в реакторе.

Сообщение отредактировано: trainer - 09.01.14, 11:50

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

Цитата --Ins-- @ 09.01.14, 11:01

Если в дельфи при вызове конструктора происходит исключение, то вызывается деструктор, чтобы освободить все то, что успело создаться в конструкторе до исключения - сборщика мусора то нет. Так вот, если на момент исключения в конструкторе что-то еще не создалось, то только в этом случае нужна проверка на nil.

После плюсов это кажется дикостью

Это и без плюсов дикость

Цитата --Ins-- @ 09.01.14, 11:45

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

Кстати а когда объект будет удален? Вот вызвал я FreeAndNil. Объект то уже удален? Я имею ввиду не обнулен, а именно удален физически, память очищается после FreeAndNil ?

Цитата Wound @ 09.01.14, 11:50

Я имею ввиду не обнулен, а именно удален физически, память очищается после FreeAndNil ?

Да, конечно

Цитата --Ins-- @ 09.01.14, 11:52

Да, конечно

тогда почему в примере korvin небыло AV? т.е. мы можем запросто один объект присвоить другому, и потом первый удалить с помощью FreeAndNil, а тот которому мы присвоили будет жить своей жизнью, да еще не будет занулен? И что это получается какая то кака?

Цитата Wound @ 09.01.14, 11:41

Ну блин у вас и трешняк...

Это не удалось им доказать за несколько серий многостраничных холиваров с портянками.

Добавлено 09.01.14, 11:55

Цитата Wound @ 09.01.14, 11:53

И что это получается какая то кака?

Классическая висячая ссылка получается.

Цитата --Ins-- @ 09.01.14, 11:52

Кстати а когда объект будет удален?

Методы, помеченные как destructor работают волшебным образом. Они могут быть вызваны как методы, и как деструкторы - как методы, и как деструкторы - зависит от того, как этот вызов оформлен. Например, пусть у нас есть метод destructor Destroy, тело которого пустое. Если я напишу Obj.Destroy (или Free, который вызывает Destroy внутри себя) - это деструктор, он вызовет не только тело Destroy, но и освободит память (TObject.FreeInstance). Если же я напишу inherited Destroy в перекрытом деструкторе потомка этого класса - это вызов Destroy как обычного метода, т.е. просто будет выполнено пустое тело. А память будет освобождена уже после отработки даже моего тела Destroy

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