| Форумы
ЧАТ |
Орешник |
|
| Форумы -» | Основная («Начинающим»)/ Базы / WinAPI / Компоненты / Сети / Media / Игры / Corba и COM / KOL / FreePascal / .Net / Прочее / RSDN.ORG |
|
| ||
|
|
Новости |
Поиск |
FAQ |
Статьи |
Книги |
Новости VCL
| | Форумы ЧАТ |
Орешник |
|
| |||
| |||
| |||
« предыдущая ветвь | форум | следующая ветвь »
Освобождение ресурса в finally
Arinyshka © (2008-04-23 12:17:00)
Страницы: < 1 2 ... 18 19 20 21 22 23 24 ... 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 ситуация не менялась.
Loginov Dmitry (2008-04-25 20:45:00) [401]> Дело в том, что вероятность того, что TBitmap или TJPEGImage
> дадут exception в конструкторе - ну практически нулевая.
+1
Даже при стихийном действии скорее погорит все напрочь, чем тут exception возникнет :)
На практике доводилось юзать только один класс, в котором exception в конструкторе возникает (TFileStream). Других щас и не припомню...
Leonid Troyanovsky (2008-04-25 18:37:00) [402]
> Восхищенный (25.04.08 18:30) [250]
> "Попросил" он, видите ли. Доложить.
Простите, г-н генерал-майор, засранца.
Говорила ж мама: увидел анонима - отойди.
--
Regards, LVT.
Восхищенный (2008-04-25 18:30:00) [403]> Leonid Troyanovsky © (25.04.08 18:26) [249]
Не юли. Все ты прекрасно понял.
"Попросил" он, видите ли. Доложить.
И хватит об этом.
Leonid Troyanovsky (2008-04-25 18:26:00) [404]
> Восхищенный (25.04.08 17:14) [248]
> Тебе не приходило в голову, что ты тут вовсе не наместник
> бога? И что тут найдутся люди, которые Delphi и Конопку
> знают, как минимум не хуже тебя?
Смотрел, смотрел и не усмотрел никакого снобизма.
Бо, нет у меня ни Конопки, ни Шрайбера, ни других Руссиновичей
под рукой.
Поэтому и попросил.
Ну, а если ломает, то извини, сами уж как нибудь.
--
Regards, LVT.
ANB (2008-04-25 17:14:00) [405]Домой пора.
Вобчем то по поводу объекты + трай файнелли я уж лучше послушаю Сашу Просторова.
Как то привык доверять его мнению. Сколько раз проверял даже спорные советы - он всегда оказывался прав. А если не знает, как лучше - так и советов не дает.
А тем, кто сомневается в его авторитете :
http://softwarer.ru/certifications.html
Ну и плюс мона зайти на SQL.ru, поближе познакомится.
Восхищенный (2008-04-25 17:14:00) [406]> Leonid Troyanovsky © (25.04.08 16:42) [245]
> Есть необходимость?
ОК, от посыпания головы пеплом я тебя тоже освобождаю. Такой необходимости действительно нет.
Есть другая неоходимость - поменьше снобизма проявлять. Вот такого, например: "Полистай Конопку и доложи".
Тебе не приходило в голову, что ты тут вовсе не наместник бога? И что тут найдутся люди, которые Delphi и Конопку знают, как минимум не хуже тебя?
Надеюсь, ты это усвоил.
ANB (2008-04-25 17:06:00) [407]
> В этом и отгадка того, почему обычно не стоит обрамлять
> вызов
> конструктора, бо, в ООП для хранения ссылок на объекты более
> естественны поля, а вовсе не локальные переменные.
Я не говорил, что не надо обрамлять. А если отвалится создание третьего объекта (предположим, что нам надо 3 файлстрима, у которых вероятность рэйза не равна нулю), что будет с первыми двумя ? Опять вложенные трай городить ?
Leonid Troyanovsky (2008-04-25 16:42:00) [408]
> Восхищенный (25.04.08 16:37) [243]
> И что тогда, о великий спорщик? Ты публично посыпешь голову
> пеплом?
Есть необходимость? :)
Правило простое - для методов диспетчеризации - dynamic.
Остальное - virtual.
Я освободил тебя от перечитывания Конопки ;)
--
Regards, LVT.
Восхищенный (2008-04-25 16:37:00) [409]> Leonid Troyanovsky © (25.04.08 16:24) [242]
> Полистай Конопку и доложи, плиз, а то у меня под рукой нет.
Уговорил. Вечером доложу (сейчас его тоже нет под рукой). С указанием точной цитаты и точного номера страницы. На чем, полагаю, спор и будет завершен.
Только имей в виду следующее. Книгу Конопки я знаю чуть ли не наизусть, поэтому точно помню, что о выборе "virtual vs dynamic" он действительно говорит. И точно помню, что именно он об этом говорит. И точно знаю, что в итоге ты окажешься неправ.
И что тогда, о великий спорщик? Ты публично посыпешь голову пеплом?
Leonid Troyanovsky (2008-04-25 16:37:00) [410]
> Игорь Шевченко © (25.04.08 16:07) [237]
> С точностью до наоборот, чем реже, тем больше смысла делать
> динамическим
Был неправ, sorry.
Dynamic methods are useful when a base class declares many overridable methods which are inherited by many descendant classes in an application,
but only occasionally overridden.
--
Regards, LVT.
Leonid Troyanovsky (2008-04-25 16:24:00) [411]
> Восхищенный (25.04.08 16:11) [239]
> Поэтому динамический метод хорош как раз тогда, когда вероятность
> его перекрытия невелика.
У метода диспетчеризации вероятность перекрытия весьма ненулевая.
И, вот именно оные рекомендовали к динамическим.
Полистай Конопку и доложи, плиз, а то у меня под рукой нет.
Но, оное обсуждение весьма академично, бо, пользующих ныне
dynamic можно счесть по пальцам одной руки.
--
Regards, LVT.
jack128_ (2008-04-25 16:20:00) [412]
> Спор прекращаю.
жаль, я хотел узнать, что у меня за
>небольшие проблемы с пониманием сути базовых терминов ООП, поэтому смысла нет.
-)
Leonid Troyanovsky (2008-04-25 16:18:00) [413]
> Игорь Шевченко © (25.04.08 16:07) [237]
> С точностью до наоборот, чем реже, тем больше смысла делать
> динамическим
Путаница между "частыми вызовами" и "частыми перекрытиями".
А про диспетчеризацию (это ж юзеровские действия) -
time-critical - не критично.
--
Regards, LVT.
Восхищенный (2008-04-25 16:11:00) [414]> Leonid Troyanovsky © (25.04.08 15:58) [235]
Тут смысл простой. Если динамический метод не перекрыт, то по скорости он не уступает виртуальному, а по компактности - лучше. То есть, имеет преимущество. Но как только мы начинаем его перекрывать, это преимущество начинает снижаться - и чем больше наследников его перекрыли, тем больше снижение. Поэтому динамический метод хорош как раз тогда, когда вероятность его перекрытия невелика.
Leonid Troyanovsky (2008-04-25 16:10:00) [415]
> ANB (25.04.08 09:51) [195]
> что ты пользуешь поля класса, а я - локальные переменные,
> посему мне надо их нилить, а за тебя это неявно конструктор
> сделает.
В этом и отгадка того, почему обычно не стоит обрамлять вызов
конструктора, бо, в ООП для хранения ссылок на объекты более
естественны поля, а вовсе не локальные переменные.
--
Regards, LVT.
Игорь Шевченко (2008-04-25 16:07:00) [416]
> Мне лень искать, но была такая рекомендация от борландов,
> мол,
> чем чаще предполагается замещать метод, тем предпочтительней
> его сделать динамическим, например, для обработки событий.
>
С точностью до наоборот, чем реже, тем больше смысла делать динамическим
Восхищенный (2008-04-25 16:06:00) [417]> Leonid Troyanovsky © (25.04.08 15:58) [235]
> была такая рекомендация от борландов, мол, чем чаще предполагается
> замещать метод, тем предпочтительней его сделать динамическим,
> например, для обработки событий.
Ты перепутал. Рекомендация на эту тему от борландов действительно была, но полностью противоположная той, что ты изложил.
Кстати, они сами своей же рекомендации и следуют. Загляни в VCL - все методы диспетчеризации событий у них динамические. А вот методы, которые наследники наверняка перекроют - все до одного виртуальные.
> jack128_ (25.04.08 15:57) [234]
Спор прекращаю. Извини, но у тебя небольшие проблемы с пониманием сути базовых терминов ООП, поэтому смысла нет.
Leonid Troyanovsky (2008-04-25 15:58:00) [418]
> Восхищенный (25.04.08 15:51) [232]
> Динамический действительно компактнее. Но медленнее. Поэтому
> ты неправ.
Мне лень искать, но была такая рекомендация от борландов, мол,
чем чаще предполагается замещать метод, тем предпочтительней
его сделать динамическим, например, для обработки событий.
А, во-ще, тут и не стоило даже поминать динамический.
Virtual forever.
--
Regards, LVT.
jack128_ (2008-04-25 15:57:00) [419]
> А класс-потомок может добавить парочку своих, статических
см [226]
> Что полностью противоречит [211] и о чем говорилось в [213].
ты не находишь, что "вынес изменяемый кусок кода" и "вынес НЕизменяемый кусок кода" - это лингвистические изыски??
Главное: было X функций -> стало Y функций. При этом - совпадающих участков кода - стало меньше.
Восхищенный (2008-04-25 15:55:00) [420]> Leonid Troyanovsky © (25.04.08 15:48) [230]
Небольшое уточнение: но медленнее при замещении наследниками (особенно, многократном). Поэтому ты неправ.
| |
