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

← →
Piter © (2007-11-15 15:04) [280]

Юрий Зотов © (15.11.07 15:00) [279]
Чи-го? Программа завершилась, ресурс остался открытым - и это не чушь?

программа завершилась, а библиотека так и не была выгружена из памяти, впрочем как и образ EXE. Это же вы чушью не считаете почему-то?

Программа завершилась, а ресурс остался открытым?

← →
Юрий Зотов © (2007-11-15 15:12) [281]

> Piter © (15.11.07 15:04) [280]

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

← →
reonid © (2007-11-15 15:18) [282]

DiamondShark © (15.11.07 13:57) [276]

> Не класс, а программист.

> У тебя есть контракт класса, в котором сказано: уходя гасите всех.
> В чём проблема?

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

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

← →
Плохиш © (2007-11-15 15:23) [283]

прикольная ветка :-))
даже прикольней веток "Windows vs. Lunix" :-)))
пустой бесконечный цикл...

← →
Romkin © (2007-11-15 15:25) [284]

> прикольная ветка :-)) даже прикольней веток "Windows vs.
> Lunix" :-)))пустой бесконечный цикл...

:(

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

> reonid © (15.11.07 15:18) [282]

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

Притом каждый потомок публикует свой собственный контракт, потому что потомков этих сколько хошь, пишут их разные люди в разное время и один может ничего не знать о другом. И у одного потомка этот контракт будет называться Close, у другого - Cleanup, у третьего - Dispose, у четвертого - Free, у пятого - FinalizeAll, а у шестого вообще по-китайски. А ты, юзер всей этой кучи потомков, должен сидеть и изучать их контракты.

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

← →
имя (2007-11-15 15:49) [286]

Удалено модератором

← →
Игорь Шевченко © (2007-11-15 16:21) [287]

Юрий Зотов © (15.11.07 15:33) [285]
reonid © (15.11.07 15:18) [282]

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

И нафига такое надо ?

← →
@!!ex © (2007-11-15 16:22) [288]

> [283] Плохиш © (15.11.07 15:23)

С появлением поста [282] все должно стать интереснее.
Ибо отмазаться как отмазывались раньше, уже не получиться..

← →
Romkin © (2007-11-15 16:29) [289]

> С появлением поста [282] все должно стать интереснее.Ибо
> отмазаться как отмазывались раньше, уже не получиться..

Да щаз! см [209] и ниже.

← →
Юрий Зотов © (2007-11-15 16:32) [290]

> Игорь Шевченко © (15.11.07 16:21) [287]

> Есть у меня хороший базовый класс

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

Пример хорошего базового класса - TObject. Он вводит пустой виртуальный деструктор, который лично ему на фиг не нужен - но тем самым он дает потомкам возможность освобождать любые ресурсы перед своим уничтожением. А юзеру (т.е., программеру) тем самым дается возможность не заботиться об освобождении чужих ресурсов, т. к. все происходит автоматически.

← →
Romkin © (2007-11-15 16:46) [291]

Игорь Шевченко © (15.11.07 16:21) [287] Игорь, ну посмотри сам, на TStream: внутре у него хендла нет. У его потомка TFileStream он уже есть. При этом в работе с ним не меняется ничего.
А тут предлагают, что у аналога TFileStream в java должен появиться метод Close, или Dispose или еще какой, чтобы закрывать поюзанный ресурс. Когда им указывают, что это как-бы не очень, ответ - введи Close в аналог TStream. Шоб було.
И все, кто его юзает, должны знать, что надо вызывать метод Close, когда работа закончена.

← →
Игорь Шевченко © (2007-11-15 16:49) [292]

Юрий Зотов © (15.11.07 16:32) [290]

> Пример хорошего базового класса - TObject. Он вводит пустой
> виртуальный деструктор, который лично ему на фиг не нужен
> - но тем самым он дает потомкам возможность освобождать
> любые ресурсы перед своим уничтожением. А юзеру (т.е., программеру)
> тем самым дается возможность не заботиться об освобождении
> чужих ресурсов, т. к. все происходит автоматически.

И чего мне с этого виртуального деструктора ? А почему он не заботится о предсказании погоды ?

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

Ага. Думает. В рамках заявленной функциональности.

TObject это вообще костыль. Вон KOL написан без TObject - ничего, справляются люди.

← →
Игорь Шевченко © (2007-11-15 16:53) [293]

Romkin © (15.11.07 16:46) [291]

Давайте отвлечемся от деструкторов, в конце концов на них свет клином не сошелся.

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

← →
Юрий Зотов © (2007-11-15 16:57) [294]

> Игорь Шевченко © (15.11.07 16:49) [292]

Игорь, пожалуйста, выдели в посте [292] те свои слова, которые по сути и доказательно. А не о предсказании погоды или декларативно.

Иначе я не смогу ответить. Потому что не нашел, на что.

← →
Игорь Шевченко © (2007-11-15 17:00) [295]

Юрий Зотов © (15.11.07 16:57) [294]

> Игорь, пожалуйста, выдели в посте [292] те свои слова, которые
> по сути и доказательно. А не о предсказании погоды или декларативно.
>
>
> Иначе я не смогу ответить. Потому что не нашел, на что.
>

Вопрос, собственно, был задан в [287]. И еще раз - давайте отвлечемся от деструкторов, на них свет клином не сошелся.

← →
Черный Шаман (2007-11-15 17:02) [296]

> Юрий Зотов © (15.11.07 16:57) [294]
>
> > Игорь Шевченко © (15.11.07 16:49) [292]
>
> Игорь, пожалуйста, выдели в посте [292] те свои слова, которые
> по сути и доказательно. А не о предсказании погоды или декларативно.
>
>
> Иначе я не смогу ответить. Потому что не нашел, на что.

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

← →
@!!ex © (2007-11-15 17:10) [297]

> И еще раз - давайте отвлечемся от деструкторов, на них свет
> клином не сошелся.

ну собственно весь спор именно о деструкторах...

← →
Eraser © (2007-11-15 17:11) [298]

> DiamondShark © (15.11.07 12:19) [256]

> Да-а?! Ну, пусть так. Тогда и для ручного вызова деструктора
> в дельфях и плюсах "существуют практически те же проблемы",
> потому что классический деструктор и метод close ничем
> не отличаются.

отличаются. тем, что destroy есть гарантированно у всех объектов.

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

← →
Romkin © (2007-11-15 17:15) [299]

> ну собственно весь спор именно о деструкторах...

Вот уж они тут совершенно не при чем. И речи о них давно уж нет.
Да, в Delphi деструктор обычно выполняет роль финализатора.
Но речь-то о том, что в java у объекта нет метода финализации. Точнее, он есть, но... см выше.

← →
@!!ex © (2007-11-15 17:16) [300]

Удалено модератором

← →
clickmaker © (2007-11-15 17:17) [301]

> Еще чуть-чуть и LInux vs Windows будет повержен

может, вернемся к той теме? :)

← →
Romkin © (2007-11-15 17:17) [302]

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

Да хотя бы не удалить, пес с ним, пусть этим GC занимается. Нужна возможность финализировать объект. Однообразная. Либо явно, либо автоматом, сразу, как только нужда в данном объекте отпала.

← →
Игорь Шевченко © (2007-11-15 17:19) [303]

Eraser © (15.11.07 17:11) [298]

> вообще это серьезный недостаток системы с GC. По-сути задекларировано,
> что объекты освобождать не надо, их автоматически освободит
> сборщик муссора, только гарантии на это никто не дает )
> странно как-то.

А что странного ? Сборщик мусора не выполняет свою работу, да ?

← →
Azize © (2007-11-15 17:21) [304]

> Мля... уже 300 сообщений....
> Еще чуть-чуть и LInux vs Windows будет повержен...
>

Тут война миров происходит. революция можно сказать

← →
Piter © (2007-11-15 17:21) [305]

Юрий Зотов © (15.11.07 15:12) [281]
Миш, в третий раз тебе уже говорю - сначала разберись, что такое ресурс, потом будешь спорить

Юрий, давайте вы будете говорить в чем я неправ вместо того, чтобы говорить, что мне не надо писать?
Или в другом случае просто не отвечать на мои посты.

Юрий Зотов © (15.11.07 15:12) [281]
Только что ты смешал в одну кучу логическое и физическое освобождение ресурса.

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

Ну и с java тоже самое - считайте, что логически ресурса больше нет, вот и все. Да, да, так и считайте.

Просто вы знаете, что он есть, вас это и тревожит. Но вы также знаете, что библиотека тоже осталась в памяти, хоть вы и вызвали FreeLibrary. Но если в случае с Windows вы это считаете скрытым механизмом реализации, кеширование и что вам угодно - и не паритесь, то с java вы решили попариться.

Это пережитки логики так сказать native-языков. Как раз проблема с утечками ресурсов в грамотных специалистов забила раскаленными гвоздями рефлекс, если создал - уничтожь, выделил - освободи, на каждый New должен быть свой Dispose, на каждыый GetMem - свой FreeMem. Это настолько вдолблено в голову, что мозг противится тому, что может быть иначе. Столько ошибок и ожогов было на этом поприще - что работа по иному не представляется возможным.

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

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

В чем я с вами согласен, дядь Юра, так это в том, что нефиг вообще было включать в Java такое понятие как finalize, если оно имеет такой глючный механизм исполнения. Может выполнится, а может и нет, это считай говорит о том, что никакого кода туда лучше вообще не писать, а тогда и само понятие нафиг не нужно.

← →
clickmaker © (2007-11-15 17:23) [306]

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

Жадные до ресурсов (которых дефицит обычно) объекты имеют Dispose(). Например, Brush/ Pen и т.п. нужно явно освобождать. А то легко можно схлопотать Out of memory, хотя ее, казалось бы завались.
А за остальными мусорщик придет. Вопрос времени только )

← →
@!!ex © (2007-11-15 17:23) [307]

> [305] Piter © (15.11.07 17:21)

Ответьте на [282]?

← →
Romkin © (2007-11-15 17:25) [308]

Piter © (15.11.07 17:21) [305] Хм. Тогда зачем в java сборщик мусора?

> Игорь Шевченко © (15.11.07 17:19) [303]

вполне выполняет, но меняется весь смысл деструктора..
по-сути разработчики должны были предусмотреть какой-нибудь виртуальный finalize в джавовском TObject, как правильно заметил Romkin © (15.11.07 17:17) [302]. Чтобы с ресурсами можно было работать по аналогии с классическим подходом.
а так GC конечно хорошо, но могло бы быть и лучше... в идеале деструктор должен вызываться сразу после того, как пишем
obj_instance = null;и т.п.

> Игорь Шевченко © (15.11.07 17:00) [295]

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

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

> Черный Шаман (15.11.07 17:02) [296]

Про SQL - это замечательный аргумент. Еще можно о Фортране вспомнить. Правда, ни в том, ни в другом никаким ООП даже и не пахнет, но ведь это же неважно, да?

> Eraser © (15.11.07 17:26) [309]
> по-сути разработчики
> должны были предусмотреть какой-нибудь виртуальный finalize
> в джавовском TObject, как правильно заметил Romkin © (15.
> 11.07 17:17) [302]. Чтобы с ресурсами можно было работать
> по аналогии с классическим подходом.а так GC конечно хорошо,
> но могло бы быть и лучше... в идеале деструктор должен
> вызываться сразу после того, как пишем obj_instance = null;
> и т.п.

Нет, в духе java, думаю, подошло бы решение из Romkin © (15.11.07 10:34) [234], когда о финализации просят позаботится окружение, виртуальная машина же есть?

> Piter © (15.11.07 17:21) [305]

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

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

Короче, разберись с тем, что такое освобождение ресурсов. Или не спорь.

С философской точки зрения все просто.
Если ресурсы в ява приладе остались неосвобожденными, то надо привлечь к ответственности ИИ (сборщик мусора), а программист не виноват.
:)

@!!ex © (15.11.07 17:23) [307]
Ответьте на [282]?

а что там отвечать? Это логика программиста на native-языке, привыкшего работать напрямую с памятью, с байтами, битами

reonid © (15.11.07 15:18) [282]
Проблема в том, что у каждого класса, никаких ресурсов не использующих,
может быть потомок, которому нужны для внутреннего
функционирования какие-нибудь нетривиальные ресурсы

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

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

И это чистая правда. Да, может быть такой потомок и будет, но мы почему-то привыкли к стандартным ограничениям windows, мы приемлем прослойку в виде драйвера и более того набора специальных функций DirectX для работы с графикой. Но почему-то ограничения языка с автоматической сборкой мусора мы не приемлем и прослойку в виде java-машины отторгаем. А почему? А потому что не привыкли.

Я уверен, что с появлением Windows тысячи программистов занимающихся разработками игр плевались, когда им захотели запретить напрямую работать с видеокартами. А сейчас ничего, без существующей иерархии и представить что-то сложно работающее в 3D.

Romkin © (15.11.07 17:25) [308]
Piter © (15.11.07 17:21) [305] Хм. Тогда зачем в java сборщик мусора?

на такой незатейливый вопрос у меня есть только один незатейливый ответ:

"чтобы собирать мусор" ;)

Piter © (15.11.07 17:39) [314]

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

О как!
Юра, помнишь, ты код с Stream приводил? Так вот: метод close ты вызывать не должен был! Нет у этого класса никаких ресурсов, которые не уберет сборщик мусора!

> Piter © (15.11.07 17:39) [314]

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

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

> reonid © (15.11.07 15:18) [282]
>
> Проблема в том, что у каждого класса, никаких ресурсов не
> использующих,
> может быть потомок, которому нужны для внутреннего
> функционирования какие-нибудь нетривиальные ресурсы.
> Совершенно у любого.

Во-первых, это неверно. Есть куча базовых классов, у которых использование нетривиальных ресурсов может присниться только в страшном сне. Так что не у любого, а у некоторых. Так точнее.

Во-вторых, давайте будем разбираться, что это могут быть за ресурсы, и откуда они возьмутся.

Обычно у ресурсов есть некое внешнее имя (путь для файла, сетевой адрес для сокета, строка подключения для бдконнекта, ID устройства для аудиомикшера и т.п.), это естественно, т.к. для того, чтобы захватить ресурс его надо сначала как-то идентифицировать.
Являются ли имена ресурсов жестко зашитыми в коде класса? Если да, то это плохой класс: тупой, непереносимый, накладывающий неоправданные ограничения на окружение. Вообще, я слабо представляю себе полезность класса, работающего с файлом с жестко заданным именем, или с жестко заданным сетевым адресом и т.п.
Значит, классу должны быть переданы имена (идентификаторы) ресурсов. Стоп. А зачем передавать имена? Гораздо лучше передать объект-обёртку для какого-то ресурса. Причём, объект самого абстрактного типа, насколько возможно, например, абстрактный стрим вместо файла. Это увеличит гибкость класса, расширит область его возможного применения. Посмотрите на имеющиеся библиотеки: именно так очень часто и делают.
Таким образом, владеть нужными ресурсами объекту вовсе даже не обязательно, можно только ссылаться.

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

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

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

Юрий Зотов © (15.11.07 17:26) [310]

> Разработчик некоего класса ведь не просто так объявил их
> виртуальными - тем самым он дал возможность разработчикам
> возможных потомков модифицировать их поведение

А если не объявил ?

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

Вот! В свое время, в момент выхода первых версий Delphi народ очень возмущался - а чего это в VCL слишком много полей объявлено, как private - когда надо почесать левой ногой правое ухо, совсем не получается такое чесание. Даже мода была писать свои классы, объявляя чуть ли все содержимое минимум protected, ну а методы, натурально, виртуальными - а вдруг кому-то понадобится доступ, а вот и он, как на ладони.

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

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

> А зачем передавать имена? Гораздо лучше передать объект-
> обёртку для какого-то ресурса. Причём, объект самого абстрактного
> типа, насколько возможно, например, абстрактный стрим вместо
> файла. Это увеличит гибкость класса, расширит область его
> возможного применения. Посмотрите на имеющиеся библиотеки:
> именно так очень часто и делают.Таким образом, владеть
> нужными ресурсами объекту вовсе даже не обязательно, можно
> только ссылаться.

Продолжи мысль пожалуйста.
1. Где мне взять этот объект-обертку.
2. Ну ссылаюсь я на него, дальше что?

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