Delphi vs C++ vs C# , ну и Java немножко, где-то ближе к старшему байту номеров страниц

Цитата --Ins-- @ 11.02.13, 16:00

Я тебе могу привести примеры элегантного использования того же BeforeDestruction

А мне можешь?

Цитата D_KEY @ 11.02.13, 16:13

де? Твое сообщение прочел - ничего конкретного там не увидел

А жаль, что ты видишь только то, что тебе нравится

Добавлено 11.02.13, 16:22

Цитата Мяут-Настоящий @ 11.02.13, 16:19

А мне можешь?

Например, отписка объекта от уведомлений

Цитата Shaggy @ 11.02.13, 15:23

2. если же ты в clear именно удаляешь поле, то это надо делать так:
anyobj.free;
anyobj:=nil
или
freeandnil(anyobj);

а иначе(если ты не заnilивашь ссылку) ССЗБ, тебе не кажется?

Хорошо.. Даже если я заnilиваю ссылку то что? Мне потом в том виртуальном методе вызванном из родительского конструктора проверять на nil?
А это ничего что я доступаюсь к члену-данных (пусть это даже заnilенная ссылка) полу-удаленного объекта?
Я то понимаю что в куче она еще "живет" до тех пор пока не разрушен весь объект - но все равно как то это тупо.

--Ins--, и? Я точно также могу это элегантно написать в деструкторе. В чем профит?

Цитата Мяут-Настоящий @ 11.02.13, 16:25

Я точно также могу это элегантно написать в деструкторе. В чем профит?

Как-то странно будет, если уведомление поступит разрушающемуся и полуразрушенному объекту. Не уверен, что это всегда пройдет бесследно.

--Ins--, как-то странно, что на объект, на который существуют активно используемые ссылки, собираются разрушать. Для этого бага даже название есть: "use-after-free". Умные указатели для этого и придуманы.

Цитата Shaggy @ 11.02.13, 16:07

нет, не спрашиваю

Это я спрашивал людей
http://delphi.frantic.im/delphi-tdd/#comment-770 (SomeKindOfMonster - это я, так как ник автора блога Frantic, мне пришла в голову ассоциация с двумя песнями из одного альбома Металлики)

Цитата

Привычка с предыдущего места работы – там это было в корпоративном стандарте по форматированию кода.

Цитата

Что же касается использования внутри try..finally — лучше перестраховаться. FreeAndNil не спасет от ошибок доступа и не исправит их, но позволит оперативно обнаружить.

А вот точка зрения нашего Delphi MVP:
http://www.gunsmoker.ru/2009/04/freeandnil-free.html

Цитата

Однако, я хочу показать, что вызова Free следует избегать, где это возможно, заменяя его на вызов FreeAndNil, вот так:

(и приводит код, аналогичный моему)

Цитата

Заметьте, что речь идёт именно о замене Free на FreeAndNil везде. Не просто об использовании FreeAndNil, когда вы хотите проверять ссылку на nil, а именно - целиком и полностью везде. Т.е. не писать Free вообще никогда. Да, включая сценарии с локальными переменными.

Цитата Shaggy @ 11.02.13, 16:07

это крайность(относительно безобидная), из разряда:

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

Цитата --Ins-- @ 11.02.13, 16:07

А Java культивирует преждевременную пессемизацию, и че?

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

Сейчас Ник Ходжес читает старую-престарую книгу Head First Design Patterns для Джавы (и я тоже, кстати, ее читаю - отличная книга). И ведет блог о своих впечатлениях, дает примеры реализации паттернов на Дельфях. И его изыскания пользуются популярностью: http://smartmobilestudio.com/2013/02/08/de...terns-observer/

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

Сообщение отредактировано: [S]mike - 11.02.13, 16:33

Цитата Shaggy @ 11.02.13, 16:16

у списка нет метода clear(или аналога)?

Да есть там все.
Просто вот тут как раз то непонимание Инсом почему в С++ в классе члены-данных могут хранится не как ссылки (указатели), а по значению - т.е. как есть.

Цитата Мяут-Настоящий @ 11.02.13, 16:29

--Ins--, как-то странно, что на объект, на который существуют активно используемые ссылки, собираются разрушать.

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

Цитата [S]mike @ 11.02.13, 16:29

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

Нет, потому что о паттернах проектирования можно писать без привязки к какому-либо языку И читать - тоже. Кстати, статей по использованию паттернов в delphi - валом, я и сам таких писал.

Добавлено 11.02.13, 16:40

Цитата Chow @ 11.02.13, 16:31

Просто вот тут как раз то непонимание Инсом почему в С++ в классе члены-данных могут хранится не как ссылки (указатели), а по значению - т.е. как есть.

А, ну т.е. ты привел пример проблемы в с++, которой бы в дельфи и не возникло, и говоришь что дельфи - плохой язык?

Добавлено 11.02.13, 16:44

Цитата [S]mike @ 11.02.13, 16:29

А вот точка зрения нашего Delphi MVP:

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

Chow, я про первый вариант

Цитата Chow @ 11.02.13, 16:24

А это ничего что я доступаюсь к члену-данных (пусть это даже заnilенная ссылка) полу-удаленного объекта?

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

если же вызов этого метода приводит объект в полу-удалённое состояние и для тебя это неожиданность
то даже незнаю что и сказать
может Qraizer тебя просветит, он помнится на эту тему писал (инварианты! инварианты! инварианты! )

Цитата --Ins-- @ 11.02.13, 16:39

и говоришь что дельфи - плохой язык?

Во-первых я такого не говорил. А во-вторых я просто привел пример "из жизни" когда, скажем так, "особенность" языка Делфи (полиморфизм в конструкторах/деструкторах) значительно усложняет использование библиотек написанных на оном в разработке программ на других языках.

И все равно.. Даже на Делфи мне б не понравилось доступаться к члену-данных полуразрушенного (пусть даже к зануленой ссылке) в момент, когда я знаю что этот член данных принадлежит к той части объекта которая УЖЕ разрушена.

Цитата --Ins-- @ 11.02.13, 16:39

А что, ты предлагаешь держать его до тех пор, пока от него все поставщики событий сами не отпишут? Вот поэтому в Java-х/шарпах, в которых не может быть мемликов в принципе, память и кончается.

Так в Джаве есть и средства, для того чтобы с такими ликами бороться. А что есть в Дельфях? ReportMemoryLeaksOnShutdown?

Цитата --Ins-- @ 11.02.13, 16:39

Кстати, статей по использованию паттернов в delphi - валом, я и сам таких писал.

Статей - да (читай выше об энтузиастах). Но книг - нету.

Цитата --Ins-- @ 11.02.13, 16:39

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

Цитата Shaggy @ 11.02.13, 16:45

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

Так.

Цитата Shaggy @ 11.02.13, 16:45

и если ты удаляешь в нём поле, то это штатная ситуация(ведь ты сам так захотел? и да, при последующем использовании поля нужны проверки)

Я в нем не удаляю поле - а доступаюсь к своему члену-данных.
Пока объект жив - все чудесно: хоть стопицот раз вызывай (что и делается) этот clear - все ок.

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

Цитата [S]mike @ 11.02.13, 16:47

Так в Джаве есть и средства, для того чтобы с такими ликами бороться.

В Java есть культ, что утечек не бывает и за памятью следить не надо А в Delphi есть культ - что следить надо самому и внимательно.

Цитата Chow @ 11.02.13, 16:51

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

и?
чем это отличается от ситуации:
1) вызвали clear(который удалил внутренний список)
2a) повторно вызвали clear(который попытается снова удалить список)
2б) удалили объект(в деструкторе которого ... ну ты понял)

т.е. проблема совсем не в том, что clear вызывается из деструктора предка