Мастера DELPHI (документация, исходники, скачать)

Основная («Начинающим»)/ Базы / WinAPI / Компоненты / Сети / Media / Игры / Corba и COM / KOL / FreePascal / .Net / Прочее / RSDN.ORG

« предыдущая ветвь | форум | следующая ветвь »

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

Страницы: < 1 2 ... 13 14 15 16 17 18 19 ... 32 33 >
Arinyshka © (2008-04-23 12:17:00)
Не подскажете еще один момент:
Есть процедура, выглядит примерно так

procedure TSetPayFrm.BtnAddImageClick(Sender: TObject);
var TempBitmap:TBitmap;
begin
if not(opendialog1.Execute) then exit;
try
TempBitmap := TBitmap.Create;
TempBitmap.LoadFromFile(OpenDialog1.FileName);
finally
TempBitmap.Free;
end;
end;

На освобождение TempBitmap.Free; выдает варнинг
[Warning] uSetPaymentMain.pas(313): Variable 'TempBitmap' might not have been initialized
Не смертельно, но непонятно... почему варнинг? При изменениии условия и включении всей конструкции в один блок begin..end ситуация не менялась.

Loginov Dmitry (2008-04-29 07:55:00) [301]
> Только... жаль, но ведь все равно не поймут. Кто может понять,
> тот уже и сам давно все понял и в объяснениях не нуждается,
> а кто еще не дозрел (шишек еще достаточно не набил) - тот
> один хрен не поймет. Увы.

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

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

Германн (2008-04-29 02:43:00) [302]

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

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

Германн (2008-04-29 02:15:00) [303]

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

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

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

Восхищенный (2008-04-29 01:56:00) [304]
> Германн © (29.04.08 01:40) [348]

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

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

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

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

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

Германн (2008-04-29 01:40:00) [305]

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

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

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

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

Восхищенный (2008-04-29 01:08:00) [306]
> Palladin © (29.04.08 00:11) [346]

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

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

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

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

Palladin (2008-04-29 00:11:00) [307]

> 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. на все комментарии/вопросы/замечания/наезды отвечу уже завтра...

Loginov Dmitry (2008-04-28 23:53:00) [308]
> "Mенее предпочтительный" - это осетрина второй свежести.

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

Восхищенный (2008-04-28 23:39:00) [309]
> Loginov Dmitry © (28.04.08 23:11) [343]

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

Loginov Dmitry (2008-04-28 23:11:00) [310]
> А аргументы могут иметь значение только на данном коде,
> но если добавить сюда вместо точек, что-то, то их значимость
> стремится к нулю.

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

Loginov Dmitry (2008-04-28 23:06:00) [311]
> Вот какой-нибудь читатель, который вообще не в курсе проиходящего,
> читал твою статью, потом "другую".... потом "третью"

то он ПСИХ!

Шутка))

{RASkov} (2008-04-28 22:54:00) [312]
> [339] Loginov Dmitry © (28.04.08 22:40)
> Кстати, вновь подправил статью

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

Anatoly Podgoretsky (2008-04-28 22:46:00) [313]
> 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;
По читабельности, а строк всего на две строки больше.
А аргументы могут иметь значение только на данном коде, но если добавить сюда вместо точек, что-то, то их значимость стремится к нулю.

Loginov Dmitry (2008-04-28 22:40:00) [314]
Кстати, вновь подправил статью, учтя ВСЕ замечания, присутствующие в данной ветке.

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

Loginov Dmitry (2008-04-28 22:07:00) [315]
Вопрос созрел следующий. Дан код:

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!
Эдакое соревнование ;)
Так почему же код, выигравший в данном "соревновании" считается дилетанским? )

Palladin (2008-04-28 18:51:00) [316]
так... пойдем дальше... :)

> 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 раз перестрахуется и породит, эту, так всеми ненавистную, сущность, никакого ущерба общему видению проекта она не принесет, а будет немножко в сторонке и возникать на виду будет только при ближаейшем рассмотрении конкретного функционала.

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

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

Игорь Шевченко (2008-04-28 15:07:00) [317]
Собственно все зависит от программиста, а не от языка :) Можно и в Java и в .Net написать полностью процедурный код, хотя там без классов не обойтись.

Leonid Troyanovsky (2008-04-28 14:31:00) [318]

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

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

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

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

--
Regards, LVT.

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

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

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

Leonid Troyanovsky (2008-04-28 14:20:00) [320]

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

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

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

--
Regards, LVT.

Страницы: < 1 2 ... 13 14 15 16 17 18 19 ... 32 33 >

Наверх

	« предыдущая ветвь \| форум \| следующая ветвь »