delphi = pascal = языки для начинающих

← →
@!!ex © (2007-11-14 19:03) [160]

Когда художнику отдаешь ехешку.
он ее вставляет в проект, а она не запускается... отчегО?
От того что файл не найден!
Не вопрос, сейчас отдам.
А не было бы эксцепшена?
ехешка не запускается...
почему? а я х.з...
пришлите лог пожалуйста?
муторно...
кто будет туда сюда логи таскать?

← →
@!!ex © (2007-11-14 19:04) [161]

> Удаление объекта и освобождение ресурсов -- это разные операции.

Разные.
А разве они не связаны?
А то что мы имеем:
ресурсы удалены, а объект продолжает существовать...
Это гуд? ИМХО нет.

← →
DiamondShark © (2007-11-14 19:04) [162]

> Так вызов этого метода никак не связан с релизом объекта.

И что тебя смущает?

← →
@!!ex © (2007-11-14 19:06) [163]

> [162] DiamondShark © (14.11.07 19:04)

> ресурсы удалены, а объект продолжает существовать...

← →
pasha_golub © (2007-11-14 19:07) [164]

> Черный Шаман (14.11.07 18:59) [156]

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

try ShowMessage(SL[12]); except on E: EListError do ErrorHandler(); end;

а не так:

var S: string;
If not SL.GetString(S) then ErrorHandler() else ShowMessage(S);

← →
DiamondShark © (2007-11-14 19:11) [165]

> @!!ex © (14.11.07 19:04) [161]
> > Удаление объекта и освобождение ресурсов -- это разные
> операции.
>
> Разные.
> А разве они не связаны?

Нисколько.

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

> А то что мы имеем:
> ресурсы удалены, а объект продолжает существовать...
> Это гуд? ИМХО нет.

А на самом деле пофиг.
Как выглядит "освобождённый" объект с освобождёнными ресурсами? Область памяти с мусором.
Как выглядит объект с освобождёнными ресурсами и с потерянными ссылками? Область памяти с мусором.

Вся разница только в алгоритме, который эту мусорную память повторно использует.

Никакой мистики.

← →
Юрий Зотов © (2007-11-14 19:11) [166]

> DiamondShark © (14.11.07 18:09) [137]

> Зачем Зотову понадобилось пихать в обобщённый контейнер такую смесь -> он ни за что не признается.

Легко. Вот реальный пример (действительно реальный, как раз с этим сейчас и работаю).

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

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

Теперь вспоминаем Вашу бессмертную фразу:

> А вот пользователь контейнера прекрасно осведомлён о свойствах
> контейнера и тех объектов, которые он собственноручно туда положил

Пользователь контейнера - это разработчик движка, то есть я. И я прекрасно осведомлен о свойствах этого контейнера, но абсолютно не
осведомлен о том, что в нем лежит и какими свойствами оно обладает.

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

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

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

В Delphi это делается элементарным разрушением объектов из кэша (а все остальное сделают сами объекты - поскольку писали их не дураки и если он ресурсы захапали, то либо совободили их сразу, либо вставили их освобождение в деструктор).

Как сделать то же самое в jav"е - вопрос. Потому что finalize, как уже выяснилось, не прокатывает. И в этом виноват именно язык, поскольку всякие там деструкторы и finalize - это методы самого корневого класса, который именно к языку и относится.

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

А насчет "грызть кактус" - скажите, Вы действительно даже не замечаете, что хамите, или только прикидываетесь?

← →
Черный Шаман (2007-11-14 19:14) [167]

> @!!ex © (14.11.07 19:01) [159]
>
> Эксцепшены очень клевая штука на стадии разработки проекта.

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

← →
Palladin © (2007-11-14 19:23) [168]

> Юрий Зотов © (14.11.07 19:11) [166]

Юрий, ну тут, блин, уже "плаванье" пошло... проектирование для ЯП с GC и для ЯП с жестким контролем времени жизни объектов именно этим и различается... нельзя с таким же подходом то...

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

я для себя усвоил, что в ЯП с GC, деструктора просто нет :) есть метод освобождения ресурсов...

← →
Piter © (2007-11-14 19:27) [169]

@!!ex © (14.11.07 18:53) [154]
А его вызываю я, когда МНЕ это нужно

а что тебе мешает вызывать некий метод объекта, который будет делать тоже самое, что Destroy в Delphi? Можешь даже назвать его также.

@!!ex © (14.11.07 18:53) [154]
на яве:
есть ресурсы, которые мне надо освободить при релизе объекта.
где я должен их освобождать?

ты хочешь сказать, что в яве нельзя самостоятельно уничтожать объекты? ;)

@!!ex © (14.11.07 18:53) [154]
ОТдельный метод? Так вызов этого метода никак не связан с релизом объекта

ух ты. Вызов Destroy вызывает обработчик OnDestroy и уничатожает объект. Что мешает на джаве сделать метод, который будет вызывать обработчик и уничтожать объект?

← →
isasa © (2007-11-14 19:30) [170]

Юрий Зотов © (14.11.07 19:11) [166]

Чисто из любопытства.
И на каком языке эта фигня пишется.

Без Types Reflection - это дурдом с тележкой. :)

← →
Юрий Зотов © (2007-11-14 19:33) [171]

> Palladin © (14.11.07 19:23) [168]

> нужно требовать существование метода освобождения занятых ресурсов

В Delphi - не нужно. А в Jav"е, как выяснилось - совершенно верно, нужно. И слава Богу, что в данном конкретном случае поезд еще не ушел и еще не поздно вставить такой метод в спецификацию интерфейса, наряду с execute.

Но это в данном случае. А если бы интерфейс был уже выпущен, года 3 назад? И уже была понаписана целая куча реализующих его классов?

Тогда в случае Delphi все работало бы "на ура", а в случае кривого джавского GC - запросто могли бы ловить утечки.

← →
Юрий Зотов © (2007-11-14 19:37) [172]

> isasa © (14.11.07 19:30) [170]

На джаве... тудыть-растудыть...
:о)

← →
Юрий © (2007-11-14 19:39) [173]

> [171] Юрий Зотов © (14.11.07 19:33)
> Но это в данном случае. А если бы интерфейс был уже выпущен,
> года 3 назад? И уже была понаписана целая куча реализующих
> его классов?

Кривая постановка задачи и незнание особенностей языка - это проблемы языка?

← →
DiamondShark © (2007-11-14 19:42) [174]

> Юрий Зотов © (14.11.07 19:11) [166]
> Легко. Вот реальный пример.

Реальный для Дельфи. Повторюсь: Вы действительно считаете, что программы на Дельфи должны переводиться на Яву дословным переводом?
Это не так.

На яве у Вас бы и задачи такой не возникло. Разработчик плагинов на Яве прекрасно осведомлён о том, что если он захватит какие-то ресурсы, никак не дав знать клиенту, он огребёт проблем.
Поэтому он либо будет освобождать ресурсы до возврата из метода execute, либо опубликует какой-либо интерфейс для явного освобождения ресурсов.

Тем более, что такой интерфейс уже есть. Как получается доступ к методу execute? Доступа к методам по имени в Дельфи нет. Значит есть либо базовый класс, либо интерфейс.

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

Ещё раз: при программировании на Яве по-явовски, а не по-дельфийски, описанной проблемы бы вообще не возникло.
Не забывайте: виртуальный деструктор -- это тоже часть интерфейса объекта, просто она досталась ему в наследство. Ява-разработчик сразу бы написал интерфес не с одним методом execute, а с двумя: execute и close.

← →
Юрий Зотов © (2007-11-14 20:16) [175]

> Юрий © (14.11.07 19:39) [173]

> Кривая постановка задачи
В чем конкретно Вы видите кривизну? Задача поставлена вполне четко.

> незнание особенностей языка
Где конкретно Вы видите незнание особенностей языка? Разве глюкавость метода finalize - это особенность языка? А незнание об этой глюкавости - это, соответственно, незнание особенностей языка?

> это проблемы языка?
Да. Глюкавость метода finalize - это проблема именно языка. Потому что это метод класса Object, который именно к самому языку и относится. Наличие GC и декларация того, что он вызывает finalize тоже относятся к языку.

← →
iZEN © (2007-11-14 20:42) [176]

> Юрий Зотов © (14.11.07 19:33) [171]
>
> > Palladin © (14.11.07 19:23) [168]
>
> > нужно требовать существование метода освобождения занятых
> ресурсов
>
> В Delphi - не нужно. А в Jav"е, как выяснилось - совершенно
> верно, нужно. И слава Богу, что в данном конкретном случае
> поезд еще не ушел и еще не поздно вставить такой метод в
> спецификацию интерфейса, наряду с execute.
>
> Но это в данном случае. А если бы интерфейс был уже выпущен,
> года 3 назад? И уже была понаписана целая куча реализующих
> его классов?
>
> Тогда в случае Delphi все работало бы "на ура", а в случае
> кривого джавского GC - запросто могли бы ловить утечки.

GC работает с объектами. GC не обязан подбирать ресурсы.

Кстати, в AWT для окон и вручную созданных объектов типа Graphics есть метод dispose() — он говорит JVM, чтобы та выгрузила более ненужные DLL (или .SO в unix) и освободила ресурсы операционной системы.

← →
@!!ex © (2007-11-14 20:44) [177]

> [176] iZEN © (14.11.07 20:42)

НЕ читаем чтоль, что тут пишут?
Говорили уже о графических объектах, они здесь каким боком?

← →
Юрий Зотов © (2007-11-14 20:48) [178]

> DiamondShark © (14.11.07 19:42) [174]

> Реальный для Дельфи. Повторюсь: Вы действительно считаете, что
> программы на Дельфи должны переводиться на Яву дословным переводом?
> Это не так.

Вообще-то, в этом примере описана постановка задачи. Встречный вопрос - Вы действительно считаете, что постановка задачи должна быть привязана к какому-либо языку? Это не так. LOL.

> он либо будет освобождать ресурсы до возврата из метода execute,
И тогда потеряет возможность их кэширования. Потому что при следующем вызове метода execute ему придется захватвать их по новой. LOL.

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

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

> Странные какие-то объекты, вещи в себе. Выполняют непонятно что
> делающий метод без параметров и без доступа к окружению.Что делает метод execute - это известно разработчику объекта и юзеру, который собирает весь алгоритм в целом. Разработчику движка это по барабану.

Параметры и доступ к окружению у объекта есть. Я же не буду приводить здесь всю постановку задачи, там одних диаграмм хрен знает сколько. Вообще-то, могли бы и догадаться.

> при программировании на Яве по-явовски, а не по-дельфийски,
> описанной проблемы бы вообще не возникло.
Код - в студию. Java-класс, прямой наследник Object, который захватывает некоторый отличный от памяти ресурс и держит его вплоть до своего уничтожения (потому что знает, что в любой момент этот ресурс может понадобиться), а при уничтожении этот ресурс освобождает. Сам, без пинка снаружи.

Код - в студию, плз. Достаточно слов.

> Ява-разработчик сразу бы написал интерфес не с одним методом
> execute а с двумя: execute и close.
Ява-разработчик должен был бы использовать finalize и не писать никаких close.

← →
iZEN © (2007-11-14 20:55) [179]

> > это проблемы языка?
> Да. Глюкавость метода finalize - это проблема именно языка.
> Потому что это метод класса Object, который именно к самому
> языку и относится. Наличие GC и декларация того, что он
> вызывает finalize тоже относятся к языку.

Очевидно, что метод finalize() был введён в язык намеренно для таких как вы и для тех, что переходит с других неуправляемых (managed) языков. Но ошиблись в выборе аспекта функционирования, ведь сишники/дельфисты привыкли думать, что в деструкторах освобождается практически всё, что можно освободить.

Почему получилось так "глючно"? Вопрос.
Может быть хотели показать тем самым, что ручное управление временем жизни не всегда правильное решение (разработчиков Firefox, например, оно не спасает — до сих пор ловят утечки памяти в коде на C++!!!).
Может это не глюк, но "фича", которая всё же хорошо документирована. Из описания её явно следует, что не стоит освобождать захваченные ресурсы в этом методе, а предусмотреть другой способ.

Итак, метод finalize() предназначен для управления концом жизни объекта, его памяти, но не ресурса, захваченного им.

← →
Юрий Зотов © (2007-11-14 20:55) [180]

> iZEN © (14.11.07 20:42) [176]

> GC работает с объектами. GC не обязан подбирать ресурсы.
Я рад и огорчен. Рад тому, что Вы это тоже знаете, а огорчен тем, что не читаете ветку. Речь-то идет как раз об освобождении ресурсов.

> Кстати, в AWT...
Угу, солидарен с [177].

← →
Юрий © (2007-11-14 20:56) [181]

> [175] Юрий Зотов © (14.11.07 20:16)

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

← →
iZEN © (2007-11-14 21:05) [182]

> @!!ex © (14.11.07 20:44) [177]
>
> > [176] iZEN © (14.11.07 20:42)
>
> НЕ читаем чтоль, что тут пишут?
> Говорили уже о графических объектах, они здесь каким боком?
>

Мы говорим о способах освобождения ресурсов.

> Юрий Зотов © (14.11.07 20:48) [178]
> > DiamondShark © (14.11.07 19:42) [174]
> > он либо будет освобождать ресурсы до возврата из метода
> execute,
> И тогда потеряет возможность их кэширования. Потому что
> при следующем вызове метода execute ему придется захватвать
> их по новой. LOL.

Тогда, действительно, задача не имеет корректного решения при такой постановке ТЗ.
Ибо "гасить" ненужные объекты в кэше по окончании их работы есть аварийный режим (попросту abort"ируете задачи).

← →
Юрий Зотов © (2007-11-14 21:18) [183]

> iZEN © (14.11.07 20:55) [179]

> Очевидно, что метод finalize() был введён в язык намеренно для
> таких как вы и для тех, что

Для таких, как я, и для "тех, что" очевидно другое - что метод finalize() был введён в язык для того, чтобы разработчик класса имел возможность выполнить ЛЮБЫЕ (!!!) необходимые действия перед разрушением объекта. В том числе, освобождение unmanaged-ресурсов.

Очень жаль, что для таких как Вы это неочевидно. Потому что Вы не читаете даже официальную документацию по языку, на котором пишете. А если бы читали, то знали, что в ней написано слежующее (подчеркивания мои):
http://java.sun.com/j2se/1.4.2/docs/api/java/lang/Object.html#finalize()

"The finalize method may take any action, including making this object available again to other threads; the usual purpose of finalize, however, is to perform cleanup actions before the object is irrevocably discarded. For example, the finalize method for an object that represents an input/output connection might perform explicit I/O transactions to break the connection before the object is permanently discarded".

> Итак, метод finalize() предназначен для управления концом жизни
> объекта, его памяти, но не ресурса, захваченного им.

Для таких, как я, совершенно неочевидно, откуда это следует именно такой вывод, но в связи с приведенной цитатой из доки вывод этот получился довольно забавным, Вы не находите?

Тем более, что с каких это пор освобождение занятой объектом памятью стало производиться из метода этого же объекта? LOL 7 раз.

← →
Юрий Зотов © (2007-11-14 21:27) [184]

> iZEN © (14.11.07 21:05) [182]

> Тогда, действительно, задача не имеет корректного решения
> при такой постановке ТЗ.

Имеет. И выше это было показано. И помеха только одна - глюки вызова finalize.

> Ибо "гасить" ненужные объекты в кэше по окончании их работы
> есть аварийный режим (попросту abort"ируете задачи).

Оба-на! А мужики-то и не знали. А что, при нормальном, не аварийном, завершении ресурсы чистить уже не требуется?

← →
iZEN © (2007-11-14 21:31) [185]

> Юрий Зотов © (14.11.07 21:18) [183]

В общем, вы правы.

← →
iZEN © (2007-11-14 21:36) [186]

Дополню [185].

Лично я за последние 10 лет никогда не использовал finalize(), так как был осведоблён о его так называемой "ненадёжной" реализации.

← →
Romkin © (2007-11-14 21:50) [187]

Черный Шаман (14.11.07 18:05) [135] Просматриваю список...
Ошибка программиста...
Ошибка программиста...
AV - это задница...
...
Мля! %:?*!
Прошу прощения, в моих привычках не числится сокрытие собственных огрехов. Я так воспитан. Все.

← →
Romkin © (2007-11-14 21:58) [188]

Игорь Шевченко © (14.11.07 18:20) [143] А зачем? Просто налагай штраф за try/except, если не обосновано.

> Юрий Зотов © (14.11.07 20:48) [178]
>
> Вообще-то, в этом примере описана постановка задачи. Встречный
> вопрос - Вы действительно считаете, что постановка задачи
> должна быть привязана к какому-либо языку? Это не так. LOL.

В данном случае -- привязана. Потому что зоопарк классов у вас уже существует. И задача -- это наведение костылей к уже имеющимся классам.

> > он либо будет освобождать ресурсы до возврата из метода
> execute,
> И тогда потеряет возможность их кэширования. Потому что
> при следующем вызове метода execute ему придется захватвать
> их по новой. LOL.

Нет ножек -- нет конфеток.
Я ещё раз повторяю: Ява-разработчик о таких моментах помнит, и такой интерфейс никогда не изобразит. Разве что это его вторая, после хеловорлда, работа на Яве.

> А я, разработчик движка, непонятно каким волшебным образом
> узнаю об этом новом интерфейсе через три года после запуска
> программы в эксплуатацию. И немедленно доработаю движок
> под юзание этого свалившегося с Луны интерфейса. И все юзеры
> (а их будут тысячи, по всей стране) немедленно переинсталлируют
> программу. LOL.

Юродствуете? Ню-ню.
Если вы привыкли задачи решать через анус, медицина бессильна.

> Хотя выше я уже сказал и
> о том, что программа пишется на Джаве, и о том, что интерфейс
> есть.

Не сказал.

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

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

> Код - в студию.

А я нанимался?

При удалении объекта ява вызывает метод finalize().
Угу. Выше были приведены условия вызова этого метода. Лучше не нать!

С некоторыми персонажами все ясно. Могут заниматься блудословием и дальше, сколько им угодно. Адью.

> Эксцепшены очень клевая штука на стадии разработки проекта.

Угу. Только, плиз, опусти вторую половину фразы, и все будет нормально. ТАк задумано.

← →
Mambasa (2007-11-14 22:04) [193]

Юрий Зотов © (14.11.07 22:03) [191]

>С некоторыми персонажами все ясно. Могут заниматься блудословием и дальше, сколько им угодно. Адью.

Это вы исключение выбросили :)))

← →
Mambasa (2007-11-14 22:05) [194]

Mambasa (14.11.07 22:04) [193]

Юрий Зотов © (14.11.07 22:03) [191]

>С некоторыми персонажами все ясно. Могут заниматься блудословием и дальше, сколько им угодно. Адью.

Нет, вот так конечно

Это вы исключение выбросили? :)))

> Mambasa (14.11.07 22:04) [193]

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

> А если жмакать код как в голову придет, то екзепшены не
> помогут.

Тут ничего не поможет, увы

← →
Черный Шаман (2007-11-14 22:13) [197]

> Romkin © (14.11.07 21:50) [187]
>
> Черный Шаман (14.11.07 18:05) [135] Просматриваю список.
> ..
> Ошибка программиста...
> Ошибка программиста...
> AV - это задница...
> ...
> Мля! %:?*!
> Прошу прощения, в моих привычках не числится сокрытие собственных
> огрехов. Я так воспитан. Все.

Я не говорю что эти ошибки не нужно исправлять(хотя они возникают раз в 2-3 дня, отловить сложно). Я о том, что пользователю стандартное сообщение об AV ничем бы не помогло, он бы даже адреса памяти не запомнил чтобы в службу техподдержки сообщить.

> Я о том, что пользователю стандартное сообщение об AV ничем
> бы не помогло, он бы даже адреса памяти не запомнил чтобы
> в службу техподдержки сообщить.

А мой опыт говорит, что помогло бы. Хотя бы потому, что если (реально, млин!) нам звонит юзверь, и по слогам читает асес-виолейшен, то весь отдел ставится на уши до решения трамблемы. По факту.
Кстати, сугубо рекомендую: глядишь, и скрывать ничего не нать будет.
PS. Лог ведется, но сугубо параллельно, на случай, если упустили.

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

> Piter © (14.11.07 19:27) [169]
> @!!ex © (14.11.07 18:53) [154]
> А его вызываю я, когда МНЕ это нужно
>
> а что тебе мешает вызывать некий метод объекта, который
> будет делать тоже самое, что Destroy в Delphi? Можешь даже
> назвать его также.

Странно, за столько лет ни разу не приходилось вызывать деструктор явно. Может я чё не так делаю?

delphi = pascal = языки для начинающих Найти похожие ветки