Освобождение ресурса в finally

← →
{RASkov} © (2008-04-24 12:50) [80]

> [79] Kolan © (24.04.08 12:46)
> так что, имхо, классовый.

Коструктор, да. Его нужно применять к классу, иначе(если к объекту: Obj.Create;) это не конструктор а вызов метода Create без распределения памяти....

Но я зря его(конструктор) подчеркнул, так как разговор был о Free)

← →
Восхищенный (2008-04-24 12:50) [81]

> Kolan © (24.04.08 12:46) [79]

Проверь, что такое Self внутри конструктора - и имхо твое изменится, и имхом быть перестанет.

← →
Восхищенный (2008-04-24 12:57) [82]

> {RASkov} © (24.04.08 12:50) [80]

> Его нужно применять к классу, иначе(если к объекту: Obj.Create;) это не
> конструктор а вызов метода Create без распределения памяти....

Ты, возможно, удивишься, но метод Create не выделяет память даже если он был вызван и через ссылку на класс. Память выделяется другим кодом, который в этом случае автоматически вставляется компилятором перед непосредственным вызовом Create. Это просто compiler-magic фича такая и к классовым методам она никакого отношения не имеет.

← →
{RASkov} © (2008-04-24 13:01) [83]

> [82] Восхищенный (24.04.08 12:57)
> Ты, возможно, удивишься

Нет, не удевлюсь, так как то что мы видим в редакторе кода для компилятора это совсем другое :)
А честно - "не знал"... Т.е. именно такое про конструктор слышу в первый раз.

← →
Восхищенный (2008-04-24 13:20) [84]

> {RASkov} © (24.04.08 13:01) [83]

Поставь на первой строке конструктора бряк и посмотри, что будет в окне CPU перед этим бряком. Там увидишь вызов функции из System (не помню точное название, что-то типа _CreateInstance), которая реально выделяет память и создает объект (ее код можно посмтреть). А на первой строке конструктора объект уже создан и даже проинициализирован (InitInstance), и сам конструктор, по сути, всего лишь дает возможность его дополнительной (юзерской) инициализации. Ну и есть там еще блок try-except (тоже вставленный компилятором) - это уже к сабжу относится (разрушение объекта при исключении в конструкторе).

← →
Jack128_ (2008-04-24 13:43) [85]

> начит проблемы в другом месте кода и это счастье, что тебе
> удалось уловить их хотя бы опосредованно.

не фига. как раз если не обниливать переменную после уничтожения - то проблема может и не проявиться(точнее проявиться - но у юзера), а вот если юзать FreeAndNil - то ошибка ГАРАНТИРОВАННО проявиться.

var O: TObject; begin O := TObject.Create; try Caption := O.ClassType.ClassName; finally O.Free; end; Caption := O.ClassType.ClassName; // ошибочный код. Но AV не будет. end;

Поэтому я почти всегда юзаю FreeAndNil

← →
Palladin © (2008-04-24 13:57) [86]

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

← →
ANB (2008-04-24 14:10) [87]

> ЮЮ © (24.04.08 12:36) [76]
> > [74] ANB (24.04.08 12:30)
>
> > Вобчем то да. Но могут быть разные глюки потом
>
>
> Глюки после смерти? Если они есть, значит проблемы в другом
> месте кода и это счастье, что тебе удалось уловить их хотя
> бы опосредованно.

Да я не нарывался ни разу.

← →
Восхищенный (2008-04-24 14:11) [88]

> Palladin © (24.04.08 13:57) [86]

В самую точку.

← →
ANB (2008-04-24 14:13) [89]

> Palladin © (24.04.08 13:57) [86]
> Обниление идентификаторов и перенос конструктора в try выглядит
> как-то неестественно, но это так, придирка не посуществу.
> Другое беспокоит, не знаю как кто, но у меня обычно в локальных
> перменных не числится больше трех-четырех объектов, а если
> и числится, то используются они в разных временных рамках
> и на каждый идет блок try finally, если же происходит раздувание
> количества, то это первая ласточка к разделению процедуры/метода
> на несколько шагов и оформлении их в виде отдельных процедур/методов.
> Разделяй и влавствуй, как говорится. Так что, обниление
> идентификаторов, это совет тем кто не умеет структурировать
> программу и лепит все в один.

Значится не писал достаточно сложных программ. :)

← →
Palladin © (2008-04-24 14:21) [90]

> ANB (24.04.08 14:13) [89]

кто не писал? я неписал?

← →
ANB (2008-04-24 14:24) [91]

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

Естественным подходом в таком случае будет создать все объекты заранее и только по окончании процедуры удалить.

Городить вложенные 5-6 трай - файнелли - жуткий изврат. Весь код фактически вправо уйдет.

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

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

ИМХО - в функции должен быть один блок трай - файнелли.

← →
Anatoly Podgoretsky © (2008-04-24 14:26) [92]

Что только не придумают, что бы оправдать лень или не знание,
правильный код только такой
Create; try ... finally Free; end;
Никаких множественных obj := nil, много, ну и что, а если посмотреть с другой стороны, например отладка и поиск ошибок, код
Create; try Create; try Create; try Create; try ... finally Free; end; finally Free; end; finally Free; end; end;
Позволяет легко видет структуру, легко искать ошибки и это без лишних действий
Free; Free; Free; .. Free;
А кто то за такты боролся, вот они где улетели, куча не нужных Free, как было сказано, если произойдет ошибка на втором Create, то Free будет вызван только один раз. При том приведена сильно упрощеная схема, а в реальности между двумя вызовами Create может быть еще много команд.
Есть конечно редкие случае, а это серверы 24x7 где все надо обертывать множеством try, включая и Create, но таких случаев мало, в основном или лень, или ламеризм, при том с "научным" обоснованием.

← →
Palladin © (2008-04-24 14:26) [93]

> Объектов 5-6 наберется.

каких например?

← →
Игорь Шевченко © (2008-04-24 14:28) [94]

ANB (24.04.08 10:31) [36]

> В случае с одним объектом, конечно, доп.строки являются
> лишними.
> Это я по привычке пишу, чтобы потом не переделывать, если
> в процедуре понядобятся еще объекты.

Тех, кто пишет что-либо, на случай, если потребуется - давить без жалости.

← →
Ega23 © (2008-04-24 14:29) [95]

> Естественным подходом в таком случае будет создать все объекты
> заранее и только по окончании процедуры удалить.
>

А это что, необходимо делать в одном месте? Это нельзя разнести на несколько методов? И насколько велика вероятность возникновения исключения в конструкторе любого из них?
Я за 9 лет один единственный раз с raise конструктор писал (и то, вроде, можно было без этих извратов сделать).

← →
ANB (2008-04-24 14:31) [96]

> Palladin © (24.04.08 14:26) [93]
>
> > Объектов 5-6 наберется.
>
> каких например?

3 файлстрима, пара объектов для селектов к БД, объект для инсерта в БД.

← →
Игорь Шевченко © (2008-04-24 14:32) [97]

Kolan © (24.04.08 12:46) [79]

> Имхо, слово constructor подразумевает class function, так
> что, имхо, классовый.

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

Воистину www.delphilamer.ru

← →
ANB (2008-04-24 14:33) [98]

> А это что, необходимо делать в одном месте? Это нельзя разнести
> на несколько методов?

Зачем ? В итерации цикла создавать и разрушать объекты - это извращение.

← →
Anatoly Podgoretsky © (2008-04-24 14:39) [99]

> Игорь Шевченко (24.04.2008 14:28:34) [94]

И вычитать из их кармана, за расточительство.

← →
Ega23 © (2008-04-24 14:39) [100]

> Зачем ? В итерации цикла создавать и разрушать объекты -
> это извращение.

Создание и инициализация объектов - в один метод, цикл - во второй, финализация и удаление объектов - в третий...
Метод больший, чем на один экран - сразу настораживает.

← →
Игорь Шевченко © (2008-04-24 14:41) [101]

ANB (24.04.08 14:33) [98]

> В итерации цикла создавать и разрушать объекты - это извращение.

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

Если надобностью диктуется создать их внутри итерации цикла и удалить в конце итерации цикла, то их надо создавать внутри итерации цикла и не иначе.

← →
Игорь Шевченко © (2008-04-24 14:43) [102]

> Создание и инициализация объектов - в один метод, цикл -
> во второй, финализация и удаление объектов - в третий..
> .
> Метод больший, чем на один экран - сразу настораживает.

Нету универсального решения

← →
ANB (2008-04-24 14:43) [103]

> Ega23 © (24.04.08 14:39) [100]
>
> > Зачем ? В итерации цикла создавать и разрушать объекты
> -
> > это извращение.
>
>
> Создание и инициализация объектов - в один метод, цикл -
> во второй, финализация и удаление объектов - в третий..
> .
> Метод больший, чем на один экран - сразу настораживает.

И как вы это себе представляете с вашим подходом к блокам трай-файнели ?

← →
Ega23 © (2008-04-24 14:52) [104]

> И как вы это себе представляете с вашим подходом к блокам
> трай-файнели ?

А что с ними не так?
try-finally я использую только для объектов, время жизни которых в пределах данного метода, либо для парных операций, типа DisableControls\EnableControls

А объекты - это либо временный DataSet, либо TStream, либо TStringList, либо TBitmap или TJPEGImage. Ну TIniFile ещё возможно.
Это 95% классов, которые я таким образом использую.

← →
Ega23 © (2008-04-24 14:54) [105]

> Нету универсального решения

Универсального вообще ничего нет. Это утопия... :)

← →
Игорь Шевченко © (2008-04-24 14:56) [106]

Ega23 © (24.04.08 14:54) [105]

> Универсального вообще ничего нет.

Есть. Принцип Keep It Simple, Stupid

← →
Ega23 © (2008-04-24 15:04) [107]

> Stupid

блин. Полминуты наверное соображал, что за StupID такой... :)

← →
ANB (2008-04-24 15:08) [108]

> Ega23 © (24.04.08 14:52) [104]

Я озвучил простенькую задачу, приближенную к реальной.
Как разделить эту процедуру на три метода ?

> Восхищенный (24.04.08 12:40) [77]
> > ZENsan © (24.04.08 12:26) [72] > Constructor i Destructor
> - единственные класс методы до реализации класс> методов
> в делфи начиная по моему с 2005-ого..1. Конструктор и деструктор
> - вообще не классовые методы.2. Классовые методы реализованы
> во всех версиях Delphi, начиная аж с 1.3. В [65] Плохиш
> дал очень хороший совет. Конечно, можно и дальше переливать
> здесь из пустого в порожнее, но лучше все же последовать
> этому совету.

Посмотри http://delphi.about.com/od/objectpascalide/a/classmethods.htm
В Делфи до 2005 версии не было класс методов кроме конструкторов и деструкторов. И в описании Делфи 2005 описивается это как новоая возможность: http://dn.codegear.com/article/34324
Где пишется, что до 7 версии включительно класс методов НЕБЫЛО!

На счёт 2005.. ошибочка, помоему в ней были уже - точно не помню. Но в 7 100% никогда не было! Может просто кто-то не знает что это такое...

Тут вообще не на шутку у вас дискуссии... А по началу вопрос-то был простой и на него оветили.. А какой вариант правильный - знает только бог :)

"Маке it simple as possible, but no more!" - Как говорил Niklaus Wirth

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

type TХитыйФайлParser = class public constructor Create; destructor Destroy; override; procedure ParseFile; property Connection : TADOConnection read FConnection write SetFConnection; property FileName : string read FFileName write SetFFileName; property ErrFileName : string read FErrFileName write SetFErrFileName; end;

Palladin

type TMyClass - class
class procedure SomeProc;
end;

Потом ты пишеш в проге просто:

...
TMyClass.SomeProc;
...

Это класс-метод...
В 7 делфи такого нету. Или я ошибаюсь?

> Но в 7 100% никогда не было!

упалпацтул.
Они, вообще-то ещё в D5 были (может и раньше, просто я с D5 начинал)

> type TMyClass - class
> class procedure SomeProc;
> end;
>
> Потом ты пишеш в проге просто:
>
> ...
> TMyClass.SomeProc;
> ...
>
> Это класс-метод...
> В 7 делфи такого нету. Или я ошибаюсь?

И этот человек принимает участие в разработке JEDI....

чуваки дают.......

Не методы класса!!!! Вы вообще читаете...

Это методы класса, которые могут вызываться без создания объекта!!!

С кем я тут вообще общаюсь тогда....

> Это методы класса, которые могут вызываться без создания
> объекта!!!

они вообще с первой версии Delphi имеются.

Освобождение ресурса в finally Найти похожие ветки