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

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

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

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

← →
ANB (2008-04-29 12:31) [361]

> Вынесение внутреннего 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:35) [362]

> По моему это совершенно разные подходы.

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

← →
ANB (2008-04-29 12:38) [363]

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

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

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

← →
ANB (2008-04-29 12:46) [364]

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

Разве ?

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

← →
Восхищенный (2008-04-29 13:10) [365]

Вынужден повториться.

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

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

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

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

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

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

← →
ANB (2008-04-29 13:53) [366]

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

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

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

> ANB (29.04.08 13:53) [366]

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

← →
ANB (2008-04-29 15:53) [368]

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

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

← →
Восхищенный (2008-04-29 16:07) [369]

> ANB (29.04.08 15:53) [368]

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

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

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

← →
ANB (2008-04-29 16:20) [370]

> В результате получаем, что в [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:24) [371]

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

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

← →
ANB (2008-04-29 16:38) [372]

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

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

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

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

> ANB (29.04.08 16:38) [372]

Конечно не появятся. И что?

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

Но у нас-то - другой вариант. Мы-то, в отличие от Борланда всегда точно знаем, что и где мы поназахватывали, что и где надо освобождать. Поэтому и имеем возможность, которой у Борланда не было - строить лестницы (явные или неявные).

← →
Palladin © (2008-04-29 17:15) [374]

> Игорь Шевченко © (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:34) [375]

Palladin © (29.04.08 17:15) [374]

> А я знал, что ты не удержишься, в общем"то последние абзацы
> [337] именно тебе и посвящались...

Я собственно против догматизма :)

← →
ANB (2008-04-29 17:42) [376]

> Palladin © (29.04.08 17:15) [374]

1. По поводу придирок.
Ты одновременно защищаешь 2 противоположные позиции : каскадные трай-файнелли (кстати, классик не против них совсем, если ты внимательно читал статью, он призывает сокращать количество каскадов, причем безопасным способом) и фактически позицию классика (то, что ты перенес создание и уничтожение нужных объектов в конструктор и деструктор сути не меняет. Более того - классик предупреждает о существовании небезопасных деструкторов и что на них тоже надо обратить внимание).
2. По поводу ООП. Я тут недавно разгребал код, писанный в 90-е. Авторы построили очень стройную систему классов, спроецировали все это на БД и все было бы клево. Пока не началась модификация. Проблема в том, что писано все было на обжект паскале, соответственно без РТТИ. И в конкретном месте кода оооочень тяжко понять - метод из какого модуля таки вызывается. Сейчас лезть в эти недра вообще не рискует никто, а авторов давно уже нету.
ИМХА : ООП не панацея. Все новомодные фичи есть смысл применять, если они сокращают код, повышают его читабельность.

> что то решение в [192] например

Нетронутость основной процедуры - не бог весть какое преимущество. К тому же в процессе отладки и сопровождения она скорее всего и будет меняться чаще всего.

ЗЫ. Применение классов вместо процедур ускорения не даст. Если же дало - процедуры были очень халтурно написаны. При этом никто не мешает таки использовать классы в уместных случаях (как в последнем посте ИШ).
ЗЫЫ. Детство было, похоже, недавно. Во времена юности я работал не на 486, а на ЕС-1045 и ЕС-1035 под ОС ЕС и СВМ. :)

← →
Игорь Шевченко © (2008-04-29 17:47) [377]

> Во времена юности я работал не на 486, а на ЕС-1045 и ЕС-
> 1035 под ОС ЕС и СВМ. :)

Коллега. Я еще на 1022 успел поработать. Куда никакой VM (СВМ) не встанет :)

← →
ANB (2008-04-29 17:47) [378]

> строить лестницы (явные или неявные).

Про неявные лестницы мона поподробнее ?

← →
ANB (2008-04-29 17:53) [379]

> Игорь Шевченко © (29.04.08 17:47) [377]

Дык знаю, что коллега. Я 1020 тока видел. И помогал выносить на утилизацию. Печатная машинка, ридер, ацпу. И все ботало. ОС ЕС МФТ.

А уж чего тока не стояло у нас на 1045 : Сначала МФТ, потом МВТ, потом СВС. И коллективки : джек, фокус, примус. Мне больше всего ред понравился, но его не развернули, т.к. были проблемы с организацией безопасного доступа, а дописать ее так и не успели.
Зато крякнули СВМ через команды диагностики.
Год успел поковыряться с 1066. во зубряра. Работают 60 человек - и как один за компом . . .

← →
Игорь Шевченко © (2008-04-29 17:59) [380]

ANB (29.04.08 17:53) [379]

примус таки ностальгия. И без всякого ООП написан, хотя очень и очень грамотно.

от фокуса осталось воспоминание пункта "ввод текста с рукописи". И пароль "винтовка".

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

> ANB (29.04.08 17:47) [378]

> Про неявные лестницы мона поподробнее?

Нет проблем.

proc1
try
...
finally
...
end;

proc2
try
proc1;
...
finally
...
end;

В proc2 имеем лестницу, которую я обозвал неявной.

← →
ANB (2008-04-29 18:18) [382]

> Восхищенный (29.04.08 18:04) [381]

И сколько процедур придется писать, если объектов 6 ?

> Игорь Шевченко © (29.04.08 17:59) [380]

Не, ред еще на порядок круче был :
1) совсем не тормозил (практически мновенная реакция)
2) никогда не глючил
3) НЕ БЛОКИРОВАЛ консоль, т.е. прямо поверх него мона было запускать свои приложения, использующие эту же консоль. Примусу же надо было сказать, чтобы он ее освободил, а потом хапнул обратно.

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

> ANB (29.04.08 18:18) [382]

> И сколько процедур придется писать, если объектов 6?

Блин. Писал [360], надеясь, что будет не только прочтено, но и осмыслено. Потом в явном виде просил перечитать [360] внимательно. И снова-здорова... чукча не читатель?

Так. Еще раз (блин, какой я терпеливый, однако!).
:о)

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

Если при этом получаются еще и неявные лестницы (при вызовах процедур ) - и пусть себе.

← →
Palladin © (2008-04-29 19:52) [384]

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

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

← →
Игорь Шевченко © (2008-04-29 21:51) [385]

Palladin © (29.04.08 19:52) [384]

Писание не зависит от объектов и классов, неужели так трудно понять ? Сами по себе ни объекты ни классы не являются серебряной пулей, охотно верю, что когда они появились, их объявили панацеей в плане борьбы со сложностью, но не сложилось у них бороться со сложностью. Ну вот - объявили, а не сложилось. Бывает. Наоборот, в многих случаях они свою сложность привносят. Хороший модульный код на простом С может дать 100 очков плохому ООП-коду, с классами, паттернами и прочими связующими слоями ради самих слоев.

← →
Anatoly Podgoretsky © (2008-04-29 23:05) [386]

> Игорь Шевченко (29.04.2008 21:51:25) [385]

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

← →
Игорь Шевченко © (2008-04-29 23:31) [387]

Anatoly Podgoretsky © (29.04.08 23:05) [386]

Онтогенез повторяет филогенез :)

← →
Anatoly Podgoretsky © (2008-04-29 23:40) [388]

> Игорь Шевченко (29.04.2008 23:31:27) [387]

Ты не ругайся, а то в словарь полезу.

> Anatoly Podgoretsky © (29.04.08 23:40) [388]
>
> > Игорь Шевченко (29.04.2008 23:31:27) [387]
>
> Ты не ругайся, а то в словарь полезу.
>

Чё тут в словарь то лезть:
"Хотели как лучше, а получилось как всегда" (с)

>Игорь Шевченко ©(29.04.08 21:51) [385]

>Писание не зависит от объектов и классов, неужели так трудно понять ?

вообщето я это ни разу не опроверг и более того писание не зависит и от процедур и функций.

>Хороший модульный код на простом С может дать 100 очков плохому ООП-коду, с классами, паттернами и прочими связующими слоями ради самих слоев.

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

и второй момент я все таки привел аргументы против обниления идентификаторов и свалки их в один большой try.

и чем занимается anb? а фик его знает... пространственными измышлениями об ооп. в ответ на мои слова, что ни один серьезный продукт без ооа не реализовать.

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

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

> ANB (29.04.08 17:42) [376]

я защищаю

> каскадные трай-файнелли (кстати, классик не против них совсем,
> если ты внимательно читал статью, он призывает сокращать
> количество каскадов, причем безопасным способом)

да я их защищаю, и что с того?

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

ну и о чем речь? если ты считаешь, что я только перенес фнукционал try/finally в конструктор/деструктор, то о чем вообще с тобой разговаривать? я тебе всю ветку талдычу, что не просто перенес, не убрал каскад из try/finally, я не преследовал эту цель, убрать каскад:

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

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

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

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

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

Дальше. Про автора.
Про автора "классики" я уже написал и в чем он неправ я тоже написал, и про то в каких случаях можно схалтурить я тоже написал. Пишет он грамотно, но так же не идеально, я тоже много чего у него читал.
Заметь, "классиком" ты его обозвал, сам он на это не претендует.

На SQL ру знакомится с ним я не пойду, зачем мне это надо? Я не буду нести разумное, доброе вечное как Юрий... он тоже на vr-online сходил, но там одни чукчи, не хочу такого же негатива на свой адрес с sql.ru, хотя люди там конечно грамотные, но чувство стада сыграть вполе сможет...

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

← →
ANB (2008-04-30 10:19) [392]

> что не просто перенес, не убрал каскад из try/finally, я
> не преследовал эту цель, убрать каскад

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

> 1. избавил процедуру обработки информации от ненужных 6
> локальных объектов, что бы она выглядела как можно проще
> и что бы в ней была только работа по обработке информации,
> избавил ее от рутины, и сама обработка информации стала
> намного наглядней выглядеть.
>
> 2. я оставил задел на будущее, я абстрагировал работу с
> внешними данными, и потом позже, вместо того что бы лазить
> по процедуре вверх и вниз, когда начальство вдруг решило
> перейти на XML например, а не plain-text, изменить методы
> класса...

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

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

Не, не буду считать. Т.к. у классика, кроме сертификатов, имеется целая куча больших и толстых внедренных объектов. И ООП он знает и применяет. (частенько из-за этого мы спорили, т.к. мне его без дела применять лениво).
Главный принцип Саши (я его раньше не понимал, а терь полностью поддерживаю) "Писать быстро - значит писать правильно". Причем утверждение верно в обе стороны.

На закуску про ООП : на чем написана винда и никсы ?
Из опыта : как только разработчики начинают увлекаться проектированием классов по делу и без, там где мона обойтись процедурным подходом, так проект с вероятностью 90% заваливают. А там, где пишут опытные процедурники, как правило проект внедряется.

Palladin © (30.04.08 03:50) [390]

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

А не трудно привести примеры серьезных продуктов, реализованных с помощью ООП ?

Про серьезные продукты, реализованные без ООП я могу говорить довольно долго - это Windows, Unix, Linux, Oracle. Продукты более чем серьезные, строк кода там за миллионы.

← →
ANB (2008-04-30 10:20) [394]

> внедренных объектов

внедренных проектов

← →
Восхищенный (2008-04-30 10:56) [395]

Странный спор: ООП vs ПП (процедурное программирование).

Очевидно же, что у каждого подхода есть свои сильные и слабые стороны. Значит, вопрос надо ставить так: ООП + ПП. А не "vs".

← →
ANB (2008-04-30 11:01) [396]

> Странный спор: ООП vs ПП (процедурное программирование).

А он и не такой. Он такой :

ООП по делу и без дела вс ПП, когда оно удобнее. :)

← →
Восхищенный (2008-04-30 11:03) [397]

Кстати, некие зачатки ООП-подхода прослеживаются и в Windows: есть классы окон, экземпляры этих классов, свойства окон... Реализация у них, конечно, не объектная, но идеологически довольно похоже.

Восхищенный (30.04.08 11:03) [397]

Windows это не окна. Я скажу более - и во внутренностях Windows есть "зачатки ООП-подхода" - есть диспетчер объектов, есть базовые свойства типа объекта и т.д.
Но никакой реализацией с использованием ООП в Windows (а это более чем большая система) и не пахнет - ни наследования, ни полиморфизма, одна только инкапсуляция и та сделана искусственно.

← →
Восхищенный (2008-04-30 11:21) [399]

> Игорь Шевченко © (30.04.08 11:07) [398]

Ядро Windows - это не окна. Но и ядро - это еще не вся Windows. А вся Windows - это и окна тоже. Нужен же какой-то UI.

Даже консольные приложения - и те в окне работают. Даже у сервисов предусмотрено взаимодействие с рабочим столом.

Восхищенный (30.04.08 11:21) [399]

Мы немножко в сторону отошли. Мне все-таки хотелось бы увидеть пример серьезной системы написанной с использованием ООП.

Ну кроме Delphi, разумеется :)

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