| Форумы
ЧАТ |
Орешник |
|
| Форумы -» | Основная («Начинающим»)/ Базы / WinAPI / Компоненты / Сети / Media / Игры / Corba и COM / KOL / FreePascal / .Net / Прочее / RSDN.ORG |
|
| ||
|
|
Новости |
Поиск |
FAQ |
Статьи |
Книги |
Новости VCL
| | Форумы ЧАТ |
Орешник |
|
| |||
| |||
| |||
« предыдущая ветвь | форум | следующая ветвь »
Освобождение ресурса в finally
Arinyshka © (2008-04-23 12:17:00)
Страницы: < 1 2 ... 11 12 13 14 15 16 17 ... 32 33 >
Не подскажете еще один момент:
Есть процедура, выглядит примерно так
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 ситуация не менялась.
ANB (2008-04-30 10:19:00) [261]> что не просто перенес, не убрал каскад из try/finally, я
> не преследовал эту цель, убрать каскад
Изначально дискуссия шла : каскадный трай вс один трай с обнилением.
Приведя пример разделения кода по методам ты, не собираясь этого делать, фактически грохнул каскад. И перешел в мой лагерь :) Но по прежнему пытаешься доказать, что каскад лучше.
> 1. избавил процедуру обработки информации от ненужных 6
> локальных объектов, что бы она выглядела как можно проще
> и что бы в ней была только работа по обработке информации,
> избавил ее от рутины, и сама обработка информации стала
> намного наглядней выглядеть.
>
> 2. я оставил задел на будущее, я абстрагировал работу с
> внешними данными, и потом позже, вместо того что бы лазить
> по процедуре вверх и вниз, когда начальство вдруг решило
> перейти на XML например, а не plain-text, изменить методы
> класса...
Да она еще сложнее стала для понимания и сопровождения. Плюс форматы обмена никто резко не меняет, так что, как правило, нужно будет, чтобы работал и старый и новый функционал.
Классический пример, когда ООП только затрудняет понимание и сопровождение.
> И третий момент, интересно, вот пойду я наберу кучу сертификатов,
> на целых два например больше чем у автора, напишу кучу
> статей, на целых две больше чем у автора, причем в одной
> из статей укажу: массовое обниление - зло, и докажу это.
> И вот интересно станешь ты меня классиком сразу считать
> или нет.... :)
Не, не буду считать. Т.к. у классика, кроме сертификатов, имеется целая куча больших и толстых внедренных объектов. И ООП он знает и применяет. (частенько из-за этого мы спорили, т.к. мне его без дела применять лениво).
Главный принцип Саши (я его раньше не понимал, а терь полностью поддерживаю) "Писать быстро - значит писать правильно". Причем утверждение верно в обе стороны.
На закуску про ООП : на чем написана винда и никсы ?
Из опыта : как только разработчики начинают увлекаться проектированием классов по делу и без, там где мона обойтись процедурным подходом, так проект с вероятностью 90% заваливают. А там, где пишут опытные процедурники, как правило проект внедряется.
Palladin (2008-04-30 09:31:00) [262]
> ANB (29.04.08 17:42) [376]
я защищаю
> каскадные трай-файнелли (кстати, классик не против них совсем,
> если ты внимательно читал статью, он призывает сокращать
> количество каскадов, причем безопасным способом)
да я их защищаю, и что с того?
> (то, что ты перенес создание
> и уничтожение нужных объектов в конструктор и деструктор
> сути не меняет. Более того - классик предупреждает о существовании
> небезопасных деструкторов и что на них тоже надо обратить
> внимание).
ну и о чем речь? если ты считаешь, что я только перенес фнукционал try/finally в конструктор/деструктор, то о чем вообще с тобой разговаривать? я тебе всю ветку талдычу, что не просто перенес, не убрал каскад из try/finally, я не преследовал эту цель, убрать каскад:
1. избавил процедуру обработки информации от ненужных 6 локальных объектов, что бы она выглядела как можно проще и что бы в ней была только работа по обработке информации, избавил ее от рутины, и сама обработка информации стала намного наглядней выглядеть.
2. я оставил задел на будущее, я абстрагировал работу с внешними данными, и потом позже, вместо того что бы лазить по процедуре вверх и вниз, когда начальство вдруг решило перейти на XML например, а не plain-text, изменить методы класса...
ну что толку с тобой разговаривать, когда ты не хочешьничего понимать/признавать, уперся просто и все...
Восхищенный все это уже озвучил, и что это грозит нормальной поддержкой кода в будущем (он самодокументирован) и развитием (нет трясины рутинного кода между работы с IO и собственно самой разработкой)
но ты упорно все это игнорируешь...
И не будем мерится пиписками кто когда на чем работал, конкретные параметры железя приведены, лишь потому что на них очень видна была "тяжелось" исполнения , я тоже немалое время посвятил процедурному программированию, я тоже когда то совсем не понимал, с чем кушать ООП...
Дальше. Про автора.
Про автора "классики" я уже написал и в чем он неправ я тоже написал, и про то в каких случаях можно схалтурить я тоже написал. Пишет он грамотно, но так же не идеально, я тоже много чего у него читал.
Заметь, "классиком" ты его обозвал, сам он на это не претендует.
На SQL ру знакомится с ним я не пойду, зачем мне это надо? Я не буду нести разумное, доброе вечное как Юрий... он тоже на vr-online сходил, но там одни чукчи, не хочу такого же негатива на свой адрес с sql.ru, хотя люди там конечно грамотные, но чувство стада сыграть вполе сможет...
И третий момент, интересно, вот пойду я наберу кучу сертификатов, на целых два например больше чем у автора, напишу кучу статей, на целых две больше чем у автора, причем в одной из статей укажу: массовое обниление - зло, и докажу это. И вот интересно станешь ты меня классиком сразу считать или нет.... :)
Palladin (2008-04-30 03:50:00) [263]
>Игорь Шевченко ©(29.04.08 21:51) [385]
>Писание не зависит от объектов и классов, неужели так трудно понять ?
вообщето я это ни разу не опроверг и более того писание не зависит и от процедур и функций.
>Хороший модульный код на простом С может дать 100 очков плохому ООП-коду, с классами, паттернами и прочими связующими слоями ради самих слоев.
так речь то я веду совсем не о том, что давайте применять ооп в каждой дырке. во-первых я показал anb какое преимущество оно иногда может принести при чем в ответ например призванный показать мне, что ох как много может быть локальных идентификаторов. anb конечно этого не увидел. ну хоть другие увидят.
и второй момент я все таки привел аргументы против обниления идентификаторов и свалки их в один большой try.
и чем занимается anb? а фик его знает... пространственными измышлениями об ооп. в ответ на мои слова, что ни один серьезный продукт без ооа не реализовать.
и придирками к решению 192, и попытками доказать что можно также сделать и процедурами, говорящими лишь о том что нифика невкурено решение
в терии конечно реализовать приложение без использования ооп все таки можно, но понадобится больше людей, больше времени, больше ресурсов. и огромные затраты на каждый цикл разработки. бо будет нечеловечески сложно поддерживать исходный код.
Германн (2008-04-30 00:15:00) [264]
> Anatoly Podgoretsky © (29.04.08 23:40) [388]
>
> > Игорь Шевченко (29.04.2008 23:31:27) [387]
>
> Ты не ругайся, а то в словарь полезу.
>
Чё тут в словарь то лезть:
"Хотели как лучше, а получилось как всегда"(с)
Anatoly Podgoretsky (2008-04-29 23:40:00) [265]> Игорь Шевченко (29.04.2008 23:31:27) [387]
Ты не ругайся, а то в словарь полезу.
Игорь Шевченко (2008-04-29 23:31:00) [266]Anatoly Podgoretsky © (29.04.08 23:05) [386]
Онтогенез повторяет филогенез :)
Anatoly Podgoretsky (2008-04-29 23:05:00) [267]> Игорь Шевченко (29.04.2008 21:51:25) [385]
Да получилось, но и получилось как обычно, раньше нельзя было сложно, а как только стало можно, так сразу и накрутили и стало хуже.
Это же очень наглядно на играх наблюдалось, наращивается мощность компьютера, что бы было быстро, тут же пишутся новые игры и опять медленно и так по нарастающей, тоже и с размерами игры, одна дискета, много дискет, один СД диск - много, один ДВД и уже опять много ДВД.
Один к одному и с програмированием.
Игорь Шевченко (2008-04-29 21:51:00) [268]Palladin © (29.04.08 19:52) [384]
Писание не зависит от объектов и классов, неужели так трудно понять ? Сами по себе ни объекты ни классы не являются серебряной пулей, охотно верю, что когда они появились, их объявили панацеей в плане борьбы со сложностью, но не сложилось у них бороться со сложностью. Ну вот - объявили, а не сложилось. Бывает. Наоборот, в многих случаях они свою сложность привносят. Хороший модульный код на простом С может дать 100 очков плохому ООП-коду, с классами, паттернами и прочими связующими слоями ради самих слоев.
Palladin (2008-04-29 19:52:00) [269]:) Передо мной два консерванта... "как здорово раньше писали без объектов и классов", всхлюп, "ага, хорошее было время"... мышки кололись и плакали, но жрали кактус... :) что то не вижу я смысла продолжать...
... да, кстати, я не говорил, что ооп панацея, я лишь пытался убедить, что при грамотном подходе это качественное грамотное решение и привел еге...
Восхищенный (2008-04-29 19:14:00) [270]> ANB (29.04.08 18:18) [382]
> И сколько процедур придется писать, если объектов 6?
Блин. Писал [360], надеясь, что будет не только прочтено, но и осмыслено. Потом в явномвиде просил перечитать [360] внимательно. И снова-здорова... чукча не читатель?
Так. Еще раз (блин, какой я терпеливый, однако!).
:о)
Процедуры пишутся не для того, чтобы растащить по ним лестницу. Процедуры пишутся исходя из совсем других (известных) соображений. Если код процедуры требует try (одного или нескольких), то в ней пишутся эти try. Столько, сколько нужно - без лени, без халтуры и без лишних операций.
Если при этом получаются еще и неявные лестницы (при вызовах процедур ) - и пусть себе.
ANB (2008-04-29 18:18:00) [271]
> Восхищенный (29.04.08 18:04) [381]
И сколько процедур придется писать, если объектов 6 ?
> Игорь Шевченко © (29.04.08 17:59) [380]
Не, ред еще на порядок круче был :
1) совсем не тормозил (практически мновенная реакция)
2) никогда не глючил
3) НЕ БЛОКИРОВАЛ консоль, т.е. прямо поверх него мона было запускать свои приложения, использующие эту же консоль. Примусу же надо было сказать, чтобы он ее освободил, а потом хапнул обратно.
Восхищенный (2008-04-29 18:04:00) [272]> ANB (29.04.08 17:47) [378]
> Про неявные лестницы мона поподробнее?
Нет проблем.
proc1
try
...
finally
...
end;
proc2
try
proc1;
...
finally
...
end;
В proc2 имеем лестницу, которую я обозвал неявной.
Игорь Шевченко (2008-04-29 17:59:00) [273]ANB (29.04.08 17:53) [379]
примус таки ностальгия. И без всякого ООП написан, хотя очень и очень грамотно.
от фокуса осталось воспоминание пункта "ввод текста с рукописи". И пароль "винтовка".
ANB (2008-04-29 17:53:00) [274]
> Игорь Шевченко © (29.04.08 17:47) [377]
Дык знаю, что коллега. Я 1020 тока видел. И помогал выносить на утилизацию. Печатная машинка, ридер, ацпу. И все ботало. ОС ЕС МФТ.
А уж чего тока не стояло у нас на 1045 : Сначала МФТ, потом МВТ, потом СВС. И коллективки : джек, фокус, примус. Мне больше всего ред понравился, но его не развернули, т.к. были проблемы с организацией безопасного доступа, а дописать ее так и не успели.
Зато крякнули СВМ через команды диагностики.
Год успел поковыряться с 1066. во зубряра. Работают 60 человек - и как один за компом . . .
ANB (2008-04-29 17:47:00) [275]
> строить лестницы (явные или неявные).
Про неявные лестницы мона поподробнее ?
Игорь Шевченко (2008-04-29 17:47:00) [276]
> Во времена юности я работал не на 486, а на ЕС-1045 и ЕС-
> 1035 под ОС ЕС и СВМ. :)
Коллега. Я еще на 1022 успел поработать. Куда никакой VM (СВМ) не встанет :)
ANB (2008-04-29 17:42:00) [277]
> Palladin © (29.04.08 17:15) [374]
1. По поводу придирок.
Ты одновременно защищаешь 2 противоположные позиции : каскадные трай-файнелли (кстати, классик не против них совсем, если ты внимательно читал статью, он призывает сокращать количество каскадов, причем безопасным способом) и фактически позицию классика (то, что ты перенес создание и уничтожение нужных объектов в конструктор и деструктор сути не меняет. Более того - классик предупреждает о существовании небезопасных деструкторов и что на них тоже надо обратить внимание).
2. По поводу ООП. Я тут недавно разгребал код, писанный в 90-е. Авторы построили очень стройную систему классов, спроецировали все это на БД и все было бы клево. Пока не началась модификация. Проблема в том, что писано все было на обжект паскале, соответственно без РТТИ. И в конкретном месте кода оооочень тяжко понять - метод из какого модуля таки вызывается. Сейчас лезть в эти недра вообще не рискует никто, а авторов давно уже нету.
ИМХА : ООП не панацея. Все новомодные фичи есть смысл применять, если они сокращают код, повышают его читабельность.
> что то решение в [192] например
Нетронутость основной процедуры - не бог весть какое преимущество. К тому же в процессе отладки и сопровождения она скорее всего и будет меняться чаще всего.
ЗЫ. Применение классов вместо процедур ускорения не даст. Если же дало - процедуры были очень халтурно написаны. При этом никто не мешает таки использовать классы в уместныхслучаях (как в последнем посте ИШ).
ЗЫЫ. Детство было, похоже, недавно. Во времена юностия работал не на 486, а на ЕС-1045 и ЕС-1035 под ОС ЕС и СВМ. :)
Игорь Шевченко (2008-04-29 17:34:00) [278]Palladin © (29.04.08 17:15) [374]
> А я знал, что ты не удержишься, в общем'то последние абзацы
> [337] именно тебе и посвящались...
Я собственно против догматизма :)
Palladin (2008-04-29 17:15:00) [279]
> Игорь Шевченко © (29.04.08 10:19) [356]
А я знал, что ты не удержишься, в общем'то последние абзацы [337] именно тебе и посвящались...
> ANB (29.04.08 09:53) [355]
Ну то есть по существу сказать'то оказывается и нечего. Начинаем придираться. Да без проблем, хоть до потери сознания :) ...
В [337] я высказывал соображения по поводу того каким должно быть идеальноепостроение приложения, но не бывает идеала на свете, не бывает абсолютно черного и абсолютно белого, к тому и сказал что все мы люди, а не божественные существа.
НО, есть одно, но, халтурить имеет право только тот, кто прекрасно понимает чем это может обернуться и в случае возникновения непонятных проблем сразу моментально побежит отслеживать именно те места где он схалтурил, потому что эти места вольно-невольно, но сидят в памяти занозой... и со временем у него желание схалтурить все меньше и меньше.
Однако, халтурить, без знания чем это может грозить, - непозволительно. автор "классики" именно это и делает, он показывает как нужно халтурить, вот только чем это грозит он не рассказывает. А вот плохо это...
В [346] я заполнил этот пробел автора "классики", вот только к сожалению читатели "классика" не увидят этих строк
Причем, пробел еще не полностью заполнен, наверняка найдется еще несколько отрицательных сторон подобной халтуры, которые на первый взгляд не видны.
Кстати по предпоследнему предложению я не совсем осознал, где я чего вынес... в [337] ни капли кода, ну разве что рекорд в класс преобразованный :) так что если можно поподробней или исправься если ошибся...
Дальнейшее комментировать не буду, бо уже пошли юления... по поводу структуры без обращения на смысл конструкции... странные попытки доказать, что [192] это вред...
Как верно заметил, ээ, не буду расскрывать инкогнито :), Восхищенный, я не просто взял и куда то там чего то перенес, я построил новое видение решения. Чего ты пытаешься доказать я не понимаю...
Хотя все же прокомментирую одну высказанную тобою вещь в ANB (29.04.08 12:38) [363]. Ты знаешь, где то в "детстве", во времена 486 и TP/BP7, я решил написать одну весчь, два прямоугольника катались по экрану управляемые клавишами, и не просто катались, а могли еще вертется по осям. То бишь, что то по типу 3D, вычитал просто где то про матрицы поворота. Написал я ее в тогдашнем своем стиле, процедурного программирования. То бишь создания иерархий вызовов процедур, то что ты сейчас пропагандируешь. Потом подумал и смотрю передо мной два объекта, думаю, а чего бы все это дело в объекты (Object) не оформить, прикольно получится наверное. Ну взял и оформил, жутко коряво конечно, я тогда только только к ООП приходил, все было в зачаточном состоянии. Но результат меня поразил. Exe файл стал гораздо меньше, код поразительно ясен и самое для тебя интересное, работать стало ощутимо быстрей, как я уже позже разобрался за счет именно уменьшения количества вызовов, механизм перекрытия методов сработал. Не стало кучи сравнений, ветвлений.
Мораль сей басни такова. Стоит таки задуматься над алгоритмом, и попытаться составить его декомпозицию, и порассуждать над разными вариантами сущностей в нем заложеном, с целью уменьшить количество телодвижений для достижения определенной цели...
И еще, самое интересное, что то решение в [192] например, поможет нам здорово ускорить работу, за счет ввода механизмов кеширования в объекте IO, причем основная процедура останется нетронутой... да и еще много чего позволит, если грамотно подойти к этому вопросу....
Восхищенный (2008-04-29 17:01:00) [280]> ANB (29.04.08 16:38) [372]
Конечно не появятся. И что?
То, что Борланд придумал и использовал эту схему для автоматической и неявной обработки исключений в конструкторе? Так и правильно сделал, потому что и нет другого варианта для общегорешения проблемы обработки исключений в любомнаписанном юзеромконструкторе. Заранее же неизвестно, что это будет за конструктор, что в нем юзер понапишет и поназахватывает - вот поэтому Борланд так и сделал. Схема неэффективная (из-за двойной инициализация полей), но другого общего (независимого от кода конструктора) решения просто нет.
Но у нас-то - другой вариант. Мы-то, в отличие от Борланда всегда точно знаем, что и где мы поназахватывали, что и где надо освобождать. Поэтому и имеем возможность, которой у Борланда не было - строить лестницы (явные или неявные).
| |
