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

← →
Экс-Оригинал (2008-04-28 00:49) [320]

> Loginov Dmitry © (27.04.08 23:41) [313]

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

← →
Игорь Шевченко © (2008-04-28 00:54) [321]

Экс-Оригинал (28.04.08 00:47) [319]

Если честно - жалко. Потому что ерунды в сети и в магазинах и без автора хватает. Человек не просто, написал и успокоился, ему надо, чтобы читали, чтобы типа разумное доброе и вечное сеять.

← →
Германн © (2008-04-28 01:41) [322]

Ну да. Вот Коля Карих (и почему меня постоянно тянет написать Рарих :) тоже наверно стремился сеять разумное доброе и вечное. А сколько жертв его стремления?

← →
Loginov Dmitry © (2008-04-28 08:04) [323]

> "В секции finally должна выполняться обработка любых возникающих
> в ней исключений, в противном случае будет невозможно выполнить
> обработку других исключений. "
>
> - что-то я крайне редко видел код, подобный следующему:
>
> try
> ....
> finally
> try
> ...
> except
> ...
> end;
> end;

Не бейте! Это просто перевод хэлпа :)

> точнее, так:
> try
> { Ваш код конструктора }
> except
> Destroy;
> raise;
> end;

Спасибо! raise Пропустил :(

> "Если при выделении памяти функцией AllocMem() произойдет
> исключение, FreeMem() освободит память только для ненулевых
> указателей"
>
> что, FreeMem проверяет на nil ?

Этот код просто взят из VCL. Как я могу его осуждать? Это прихоть разработчиков. Формально FreeMem проверяет на nil, но это - недокументированная фича.

> это тоже смущение для неокрепших душ, а вдруг поверят? Тебе
> же тогда второй приз надо будет выдавать, первый Архангельскому,
> а вот правильный код
>
> constructor TSomeClass.Create;
> begin
> { Ваш код конструктора }
> end;

В смысле сам вызов конструктора защищен try..except? Ладно, подправим!

> Кстати у тебя есть большое желание писать, но надо подождать
> (если желание не пройдет), пока уровень мастерства возрастет,
> а пока только вред наносишь.

Дык я и не пишу. Всего лишь исправляю давнишнюю статью, чтобы к ней не было нареканий.

← →
Anatoly Podgoretsky © (2008-04-28 08:41) [324]

> Loginov Dmitry (28.04.2008 08:04:23) [323]

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

← →
Loginov Dmitry © (2008-04-28 09:17) [325]

Судя по ассемблерному коду, до вызова конструктора никакого try..except не вставляется. Поэтому, как ни крути, получается что-то наподобие этого:

> try
> { Ваш код конструктора }
> except
> Destroy;
> raise;
> end;

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

← →
Loginov Dmitry © (2008-04-28 09:19) [326]

> а 4 - это эмпирическая константа или как ?

Да, эмпирическая. В качестве рекомендации. Считаете, что лучше ее совсем не указывать?

← →
Игорь Шевченко © (2008-04-28 10:01) [327]

Loginov Dmitry © (28.04.08 09:17) [325]

> Судя по ассемблерному коду, до вызова конструктора никакого
> try..except не вставляется

RTFM: System.pas, _ClassCreate

А.П. верно поправил

> Да, эмпирическая. В качестве рекомендации. Считаете, что
> лучше ее совсем не указывать?

Считаю.

Считаю, что луше прислушаться к рекомендациям и не писать вовсе

← →
Восхищенный (2008-04-28 10:44) [328]

http://neogranka.com/forum/showthread.php?t=1461

← →
Восхищенный (2008-04-28 10:53) [329]

"Что изменилось? (прим.: с появлением Интернета).

Правильно. Сеть терпима к объему. Необязательно писать рассказы, необязательно учиться, как в три страницы вместить Человека, Мир и Сюжет. Можно сразу начинать с большой фантастической эпопеи.

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

Но существуй в те годы интернет - могли бы выйти и первые три.

И очень вероятно, что четвертая и пятая повести оставались бы на том же самом уровне".

© Сергей ЛУКЬЯНЕНКО.

← →
Leonid Troyanovsky © (2008-04-28 11:22) [330]

> Экс-Оригинал (27.04.08 15:39) [312]

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

--
Regards, LVT.

← →
Экс-Оригинал (2008-04-28 13:59) [331]

> . Если отстаивать последовательно
> объектную модель, то нужно было б создать временный объект,
>

Не всегда нужно плодить сущности ради выполнения кода в единственном месте.

← →
Экс-Оригинал (2008-04-28 14:02) [332]

> Восхищенный (27.04.08 14:42) [310]
> > Loginov Dmitry © (27.04.08 14:31) [309]
> Главное вот что - ты понимаешь, что совершаешь почти преступление?
>

Бред какой...

← →
Leonid Troyanovsky © (2008-04-28 14:20) [333]

> Экс-Оригинал (28.04.08 13:59) [331]

> Не всегда нужно плодить сущности ради выполнения кода в
> единственном месте.

Т.е., лучше скрестить две сущности: объектную и не совсем.

--
Regards, LVT.

← →
Экс-Оригинал (2008-04-28 14:22) [334]

> Т.е., лучше скрестить две сущности: объектную и не совсем.

Иногда да. Синтез плоской и объектной модели бывает более эффективным, а код - читабельным и прозрачным.

← →
Leonid Troyanovsky © (2008-04-28 14:31) [335]

> Экс-Оригинал (28.04.08 14:22) [334]

> Иногда да. Синтез плоской и объектной модели бывает более
> эффективным, а код - читабельным и прозрачным.

Чаще встречал обратное :)

Как раз этом случае - не поля, а неинициалированные локальные
переменные и трудности с контролем времени жизни объектов
и др., ранее здесь обсуждавшееся.

--
Regards, LVT.

← →
Игорь Шевченко © (2008-04-28 15:07) [336]

Собственно все зависит от программиста, а не от языка :) Можно и в Java и в .Net написать полностью процедурный код, хотя там без классов не обойтись.

← →
Palladin © (2008-04-28 18:51) [337]

так... пойдем дальше... :)

> ANB (25.04.08 13:40) [210]

и где"ж ты у меня этот метод то нашел? :) я написал класс-оболочку для работы с "чем то извне", что отвечает за IO. потому что ты привел все 6 объектов для своего "сложного" примера отвечающих за IO. оболочка нам позволила абстрагироватся от конкретных источников/форматов данных. вот ее смысл. + достачно ясная работа с IO в самой процедуре, всегда по одной строчке, по одному вызову метода, видно, что же происходит, это называется написание самодокументируемого кода.

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

> ANB (25.04.08 14:44) [214]
> Да я как то не прусь от ООП.

вот с этого и надо было начинать, если не знать как готовить кошек, то они и нафик не нужны, эт точно....

только, ты наверное не поверишь, но без ООА и ООП действительно сложную программу, не ту "сложную" программу в которой есть процедура работающая аж с 6ю объектами IO (ужос!), а сложную, динамически развивающуюся, с гибко построенной структурой, способной реагировать на большинство внешних изменений, реализовать практически не возможно...

> Экс-Оригинал (28.04.08 14:02) [332]
>
> > Восхищенный (27.04.08 14:42) [310]
> > > Loginov Dmitry © (27.04.08 14:31) [309]
> > Главное вот что - ты понимаешь, что совершаешь почти
> преступление?
> >
>
> Бред какой...

Тебе не понять... ты не преподавал...

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

по поводу "неплодите сущностей без необходимости" - эта фраза, которую любят цитировать некоторые товарищи, совершенно верна в случае

TPoint=Class Public X,Y:Integer; End;
(ну или чуть посложнее record взять :) )

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

грубо говоря фраза "неплодите сущностей без необходимости" относится к скелету/каркасу проекта. всегда нужно взвешивать некоторую зарождающуюся, в голове проектировщика, сущность на предмет сколько она может совершить действий (влияние на другие сущности) и сколько над ней можно совершить действий (влияние другие сущностей), + на сколько может быть изменчива сущность, можно ли взять и абстрагировать некоторые ее положения и тем самым применить к бОльшему количеству реальных объектов, именно так решается ее (сущности)судьба :)

короче сложная это штука... проектирование...

← →
Loginov Dmitry © (2008-04-28 22:07) [338]

Вопрос созрел следующий. Дан код:

InnerStream := nil; OuterStream := TMemoryStream.Create; try InnerStream := TMemoryStream.Create; ...................... finally InnerStream.Free; OuterStream.Free; end;

С одной стороны имеется недостаток: 2 присвоения одному объекту.
С другой стороны, если добавить еще один try..finally, то:
1-увеличивается число строк исходного кода
2-увеличивается объем скомпилированного кода и, как следствие, размер файла
3-падает производительность.
Надежность кода лишний try..finally не увеличивает, но дает следующие плюсы:
1-увеличивается читабельность кода (правда, на приведенном коде трудно судить об этом)
2-уменьшается число присваиваний

получается 3 vs 2!
Эдакое соревнование ;)
Так почему же код, выигравший в данном "соревновании" считается дилетанским? )

← →
Loginov Dmitry © (2008-04-28 22:40) [339]

Кстати, вновь подправил статью, учтя ВСЕ замечания, присутствующие в данной ветке.

Сейчас статья мне самому стала нравиться (а это кстати - главное :) Если что-то получается неправильно, или что-то где-то не доконца продумано, то подсознательно это всегда чувствуется (ощущается какая-то незавершенность). А сейчас чувствуется, что работа сделана не менее, чем на "хор" (я на это надеюсь, но проверять не мне, а Вам ;)

← →
Anatoly Podgoretsky © (2008-04-28 22:46) [340]

> Loginov Dmitry (28.04.2008 22:07:38) [338]

А ты сравни два кода

OuterStream := TMemoryStream.Create; try InnerStream := TMemoryStream.Create; try ...................... finally InnerStream.Free; end; finally OuterStream.Free; end;
По читабельности, а строк всего на две строки больше.
А аргументы могут иметь значение только на данном коде, но если добавить сюда вместо точек, что-то, то их значимость стремится к нулю.

← →
{RASkov} © (2008-04-28 22:54) [341]

> [339] Loginov Dmitry © (28.04.08 22:40)
> Кстати, вновь подправил статью

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

← →
Loginov Dmitry © (2008-04-28 23:06) [342]

> Вот какой-нибудь читатель, который вообще не в курсе проиходящего,
> читал твою статью, потом "другую".... потом "третью"

то он ПСИХ!

Шутка))

← →
Loginov Dmitry © (2008-04-28 23:11) [343]

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

Ну тогда правильнее 2й называть "предпочтительным", а первый - "менее предпочтительным", но не так же резко: "дилетанский"!!

← →
Восхищенный (2008-04-28 23:39) [344]

> Loginov Dmitry © (28.04.08 23:11) [343]

"Mенее предпочтительный" - это осетрина второй свежести.

← →
Loginov Dmitry © (2008-04-28 23:53) [345]

> "Mенее предпочтительный" - это осетрина второй свежести.

Ну и ассоциации!... )

← →
Palladin © (2008-04-29 00:11) [346]

> Loginov Dmitry [343]

Еще раз повторю за Восхищенным. (гы... лучше с ним не связываейтесь... :) )

все отличное от схемы

взятие ресурса try работа с ресурсом finally отказ от ресурса end

является дилетантским, и вот по каким причинам:
рамки контроля взятия/освобождения (try/finally) нужны именно для контроля конкретного ресурса, и в этих рамках мы работаем с конкретным ресурсом. Тот код, типа "классика", дилетанским является потому, что реально алгоритмически выглядит так:

1. а предахранися мы от освобождения ресурса которого мы не взяли, но так что бы при его освобождении не вылезло АВ 2. взяли основной защищаемый ресурс 3.try 4. попытались взять ресурс, который мы типа предохранили, а если не получится, то хаха, все равно Ав не будет... бебебе, я ANB, мне мона, я "классику" читаю 5. работа ... N finally N+1 по барАбану, я предохранился, возьму и освобожу может взятый, а может и не взятый ресурс... N+2 отдали основной защищенный ресурс N+3 End;

так вот, в чем проблемма такого подхода, есть такое понятие "времени использования ресурса"
дилетантство "классики" заключается в том что эта "классика" скрывает от программиста истинный временной отрезок использования объекта в коде. структура программы, увы далеко не вечна, однажды совпадающие временные отрезки жизни двух объектов, могут разойтись и тогда прийдется ломать данную двойную структуру защищения, если этого не делать то это угоражает потери наглядности кода при дальнейшем его развитии... дилетанство заключается в том что никто не задумывается, а что же будет дальше то? а дальше мы будем бегать по одному большому блоку между try и finally в поисках, а когда же мля у нас объект использоваться начинает то!! а какой где, а куда тот, а этот откуда, зачем у меня столько присваиваний в Nil то??? а?? господи, чем я раньше то думал???... одним словом, проблемы с рефакторингом :)

Второй момент, так называемые "безопасные" конструкторы. Я уже про это рассказывал. Но чет никто из поклонников "классики" не проникся. Берем, млин, шаг №2 и предпологаем, что под губительным внешним воздействием жестоко калечится шаг 1. где было предохранение от осовобождение ресурса, причем так калечит (например в память неверное значение записывается) и все на нет, и тут сразу вдруг попытка взять "типа защищенный ресурс номер два" дает сбой, по причине губительного воздействия, да такой что попытка в finally его освобождения жестоко выносит приложение за пределы видимой вселенной... вероятность такого, конечно, очень мала... так проблемма то в том что как бы нибыла она мала, но она ЕСТЬ!.. когда же вы это поймете наконец то... и у нас есть реальные шансы спастись и остаться в области наблюдаемой галактики вместо провала в другое измерение...

вот по этим причинам ни ANB, ни жексон(гуруделфи.гуглепагес.ру) с таким подходом и не напишут ни одной серьезной программы... кроме "сложнейших" процедур с 5-6 объектами (о ужос!)... да и с ними в трясине повязнут со временем...

господи, ну если вы такие избегатели каскадов из try finally, то пишите тогда так

o1:=TObject1.Create; Try o2:=TObject2.Create; Try o3:=TObject3.Create; Try o4:=TObject4.Create; Try o5:=TObject5.Create; Try o6:=TObject6.Create; Try o7:=TObject7.Create; Try и нету никаких ненавистных каскадов... одна трясина из кода процедуры, в которой вы потом увязните по уши :) Finally o7.Free; End; Finally o6.Free; End; Finally o5.Free; End; Finally o4.Free; End; Finally o3.Free; End; Finally o2.Free; End; Finally o1.Free; End;

ps. на все комментарии/вопросы/замечания/наезды отвечу уже завтра...

← →
Восхищенный (2008-04-29 01:08) [347]

> Palladin © (29.04.08 00:11) [346]

Я восхищен(ный).
:о)

Только... жаль, но ведь все равно не поймут. Кто может понять, тот уже и сам давно все понял и в объяснениях не нуждается, а кто еще не дозрел (шишек еще достаточно не набил) - тот один хрен не поймет. Увы.

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

Жди, Тимур. Щас тебе начнут объяснять, что мир неплоский. Ты ведь об этом не догадывался, правда?

← →
Германн © (2008-04-29 01:40) [348]

> Жди, Тимур. Щас тебе начнут объяснять, что мир неплоский.

А он предупредил заранее, что отвечать будет завтра. :)
И понятно почему предупредил :)

Ну и главное. Сия ветка уже давно переросла из конкретного обсуждения в весьма расплывчатое словоблудие. Да. Это словоблудие по теме ветки, но всё равно словоблудие.

P.S. То что мир не плоский все давно знают. Это не вопрос. Вопрос в том что мир не круглый :)

← →
Восхищенный (2008-04-29 01:56) [349]

> Германн © (29.04.08 01:40) [348]

> Это словоблудие по теме ветки, но всё равно словоблудие.

А why бы и not? Раз по теме - значит, не оффтоп. Правила не нарушены.

Только не словоблудие это, вот в чем фокус. Это та самая грань, где кончается простое ремесленничество и начинается искусство. Где знания уже перерастают в интуицию, в чутье, в автопилот, а из них - в красоту и надежность кода, в его читабельность, гибкость, развиваемость и поддерживаемость.

После коего перерастания становится уже можно и статьи писать.
:о)

PS
Я не пьян. И с крышей тоже все в порядке.
:о)

> Восхищенный (29.04.08 01:56) [349]
>
> > Германн © (29.04.08 01:40) [348]
>
> > Это словоблудие по теме ветки, но всё равно словоблудие.
>
>
> А why бы и not? Раз по теме - значит, не оффтоп. Правила
> не нарушены.
>
> Только не словоблудие это, вот в чем фокус. Это та самая
> грань, где кончается простое ремесленничество и начинается
> искусство. Где знания уже перерастают в интуицию, в чутье,
> в автопилот, а из них - в красоту и надежность кода, в
> его читабельность, гибкость, развиваемость и поддерживаемость.
>
>
> После коего перерастания становится уже можно и статьи писать.
>
> :о)
>
> PS
> Я не пьян. И с крышей тоже все в порядке.
> :о)
>

Всё равно это словоблудие! Но словоблудие словоблюдию рознь. Какое-то размышление над каким-то вопросом действительно могут помочь перейти ту самую "грань".

А я и не подозревал тебя в пьянстве. Но уже подозреваю, кто ты есть.
Очень много знакомого. :)

> А я и не подозревал тебя в пьянстве. Но уже подозреваю,
> кто ты есть.
> Очень много знакомого. :)
>

Может летом, в июле или августе, смогу выбраться на ММП.

> Только... жаль, но ведь все равно не поймут. Кто может понять,
> тот уже и сам давно все понял и в объяснениях не нуждается,
> а кто еще не дозрел (шишек еще достаточно не набил) - тот
> один хрен не поймет. Увы.

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

Теперь о главном: можно ли статью оставить в том виде, в котором она есть сейчас? )

← →
ANB (2008-04-29 09:44) [353]

> для своего "сложного" примера отвечающих за IO

Да. Это была самая сложная задача в моей программерской жизни. И решал я ее целых 15 минут.

← →
ANB (2008-04-29 09:46) [354]

> А ты сравни два кода
>
>
> OuterStream := TMemoryStream.Create;
> try
> InnerStream := TMemoryStream.Create;
> try
> ......................
> finally
> InnerStream.Free;
> end;
> finally
> OuterStream.Free;
> end;
>
>
> По читабельности, а строк всего на две строки больше.
> А аргументы могут иметь значение только на данном коде,
> но если добавить сюда вместо точек, что-то, то их значимость
> стремится к нулю.

По читабельности - намного хуже варианта Димы и моего.
Чем меньше в процедуре вложений, тем лучше.

← →
ANB (2008-04-29 09:53) [355]

Сравниваем :
Palladin © (28.04.08 18:51) [337]
и
Palladin © (29.04.08 00:11) [346]

В первой случае вы инициализацию вынесли в отдельный метод. При этом похерив каскадный трай - файнелли, который рекламируете во втором случае.

Вот где дилетантство.

Не удержусь, чтобы не процитировать:

"ОО-языки упрощают абстракцию, возможно, даже слишком ее упрощают. Они поддерживают создание структур с большим количеством связующего кода и сложными уровнями.
Это может оказаться полезным в случае, если предметная область является
действительно сложной и требует множества абстракций, и вместе с тем такой подход может обернуться неприятностями, если программисты реализуют простые вещи сложными способами, просто потому что им известны эти способы и они умеют ими пользоваться.
Все ОО-языки несколько склонны "втягивать" программистов в ловушку избыточной иерархии. Чрезмерное количество уровней разрушает прозрачность: крайне затрудняется их просмотр и анализ ментальной модели, которую по существу реализует код. Всецело нарушаются правила простоты, ясности и прозрачности, а в результате код наполняется скрытыми ошибкми и создает постоянные проблемы при сопровождении.
Данная тенденция, вероятно, усугубляется тем, что множество курсов по
программированию преподают громоздкую иерархию как способ удовлетворения правила представления. С этой точки зрения множество классов приравнивается к внедрению знаний в данные. Проблема данного подхода заключается в том, что слишком часто "развитые данные" в связующих уровнях фактически не относятся у какому-либо естественному объекту в области действия программы - они предназначены только для связующего уровня.
Одной из причин того, что ОО-языки преуспели в большинстве характерных для них предметных областей (GUI-интерфейсы, моделирование, графические средства), возможно, является то, что в этих областях относительно трудно неправильно определить онтологию типов. Например, в GUI-интерфейсах и графических средствах присутствует довольно естественное соотвествие между манипулируемыми визуальными объектами и классами. Если выясняется, что создается большое количество классов, которые не имеют очевидного соответствия с тем, что
происходит на экране, то, соотвественно, легко заметить, что связующий уровень стал слишком большим."

(с) Эрик Рэймонд, "Искусство программирования для Unix"

← →
ANB (2008-04-29 11:42) [357]

← →
Восхищенный (2008-04-29 12:14) [358]

> ANB (29.04.08 09:53) [355]

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

← →
Восхищенный (2008-04-29 12:15) [359]

> не отменяет.

Добавление: и не устраняет.

← →
Восхищенный (2008-04-29 12:23) [360]

И пояснение (специально для дальшесвоегоносаневидящих).

То есть - код, конечно, структурируется исходя не из какого-то там стремления разнести try, а совсем из других соображений (функционал, гибкость, читабельность и пр.). И каждый блок try пишется там, где он нужен. А уж какая у него при этом получится вложенность, в одном методе или в нескольких - это вопрос вторичный и непринципиальный, в общем-то.

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