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

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

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

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

Страницы: < 1 2 ... 12 13 14 15 16 17 18 ... 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 ситуация не менялась.

ANB (2008-04-29 16:38:00) [281]

> Нет. Не хватает инициализации переменных.

Это не переменные, а поля объекта. А процедуры - его методы. Можно даже переименовать их в конструктор и деструктор и выбросить трай-эксцепт.

От этого появятся каскады трай-файнелли ?

Восхищенный (2008-04-29 16:24:00) [282]
> Так логика совпадает ?

Нет. Не хватает инициализации переменных.

ANB (2008-04-29 16:20:00) [283]

> В результате получаем, что в [192] код безопасный (в смысле
> мемликов), а в ProcMain - опасный. Вот чем отличается.

Вот зануда.

ProcCreate
begin
try
O1 := TO.Create;
O2 := TO.Create;
O3 := TO.Create;
O4 := TO.Create;
except
ProcFree;
end;
end;

ProcFree
begin
O1.Free;
O2.Free;
O3.Free;
O4.Free;
end;

ProcMain
begin
ProcCreate;
try
...
finally
ProcFree;
end;
end;

Так логика совпадает ?

Дык гдетут каскадные трай файнелли ?

Восхищенный (2008-04-29 16:07:00) [284]
> ANB (29.04.08 15:53) [368]

> Чем отличается от моего второго варианта ?

Тем, что ProcFree не вызовется автоматически при исключении в ProcCreate. А деструктор при исключении в конструкторе - вызовется.

В результате получаем, что в [192] код безопасный (в смысле мемликов), а в ProcMain - опасный. Вот чем отличается.

ANB (2008-04-29 15:53:00) [285]

> Я видел. И что?

Чем отличается от моего второго варианта ?

Восхищенный (2008-04-29 15:49:00) [286]
> ANB (29.04.08 13:53) [366]

Я видел. И что?

ANB (2008-04-29 13:53:00) [287]

> Вынужден попросить перечитать [360] внимательно.

Смотрим : Palladin © (24.04.08 17:50) [192]. И код, в нем приведенный.

Восхищенный (2008-04-29 13:10:00) [288]
Вынужден повториться.

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

1. > Что быстрее

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

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

Ни на секунду не сомневаюсь, что он никогда не стал бы плодить методы ради лишь одной читабельности. Равно как и ради только разнесения try.

Вынужден попросить перечитать [360] внимательно.

ANB (2008-04-29 12:46:00) [289]

> И не об этом шла речь.

Разве ?

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

ANB (2008-04-29 12:38:00) [290]

> (функционал, гибкость, читабельность и пр.).

+ учет критических для скорости работы приложения мест.
Экономить такты в куске кода, через который выполнение пройдет один раз в сутки смысла нету. А вот кусок кода, который будет выполнен в цикле пару миллионов раз надо вылизывать до безобразия. Лишний вызов метода вместо линейного алгоритма - это потеря времени.

Что быстрее : X := Y;, если X - локальная переменная в случаях :
1) Y - переменная (локальная или глобальная)
2) Y - функция, возвращающая значение глобальной переменной
3) Y - поле класса
4) Y - метод класса
5) Y - свойство класса с сеттером и геттером.
?

Восхищенный (2008-04-29 12:35:00) [291]
> По моему это совершенно разные подходы.

По-моему, тоже. Второй - неверный в обоих вариантах. И не об этом шла речь.

ANB (2008-04-29 12:31:00) [292]

> Вынесение внутреннего try в отдельный метод каскада try
> не отменяет.

O1 := TO.Create;
try
O2 := TO.Create;
try
O3 := TO.Create;
try
O4 := TO.Create;
try
...
finally
O1.Free;
finally
O2.Free;
finally
O3.Free;
finally
O4.Free;

и

ProcCreate
begin
O1 := TO.Create;
O2 := TO.Create;
O3 := TO.Create;
O4 := TO.Create;
end;

ProcFree
begin
O1.Free;
O2.Free;
O3.Free;
O4.Free;
end;

ProcMain
begin
ProcCreate;
try
...
finally
ProcFree;
end;
end;

- По моему это совершенно разные подходы.
Причем второй подход будет корректен только если O1..O4 - поля класса.
И каскада во втором случае ну никак не будет.

Восхищенный (2008-04-29 12:23:00) [293]
И пояснение (специально для дальшесвоегоносаневидящих).

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

Восхищенный (2008-04-29 12:15:00) [294]
> не отменяет.

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

Восхищенный (2008-04-29 12:14:00) [295]
> ANB (29.04.08 09:53) [355]

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

ANB (2008-04-29 11:42:00) [296]

> Игорь Шевченко © (29.04.08 10:19) [356]

+1

Игорь Шевченко (2008-04-29 10:19:00) [297]
Не удержусь, чтобы не процитировать:

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

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

ANB (2008-04-29 09:53:00) [298]
Сравниваем :
Palladin © (28.04.08 18:51) [337]
и
Palladin © (29.04.08 00:11) [346]

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

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

ANB (2008-04-29 09:46:00) [299]

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

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

ANB (2008-04-29 09:44:00) [300]

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

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

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

Наверх

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