Форум: "Прочее";
Текущий архив: 2007.12.16;
Скачать: [xml.tar.bz2];
Вниз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 сборщик мусора?
← →
Eraser © (2007-11-15 17:26) [309]
> Игорь Шевченко © (15.11.07 17:19) [303]
вполне выполняет, но меняется весь смысл деструктора..
по-сути разработчики должны были предусмотреть какой-нибудь виртуальный finalize в джавовском TObject, как правильно заметил Romkin © (15.11.07 17:17) [302]. Чтобы с ресурсами можно было работать по аналогии с классическим подходом.
а так GC конечно хорошо, но могло бы быть и лучше... в идеале деструктор должен вызываться сразу после того, как пишемobj_instance = null;
и т.п.
← →
Юрий Зотов © (2007-11-15 17:26) [310]> Игорь Шевченко © (15.11.07 17:00) [295]
А ответ был дан в [290]. И от деструкторов можно отвлечься, и без них примеров достаточно. Скажем, это все методы диспетчеризации событий - да и вообще, по сути, все виртуальные (динамические) методы. Разработчик некоего класса ведь не просто так объявил их виртуальными - тем самым он дал возможность разработчикам возможных потомков модифицировать их поведение.
Игорь, ты смотришь на класс, как его юзер, как прикладник. И с этой точки зрения тебе по барабану, позаботился этот класс о своих потомках, или нет. Но как только ты начнешь писать этих самых потомка, так тебе это тут же станет вовсе не безразлично.
> Черный Шаман (15.11.07 17:02) [296]
Про SQL - это замечательный аргумент. Еще можно о Фортране вспомнить. Правда, ни в том, ни в другом никаким ООП даже и не пахнет, но ведь это же неважно, да?
← →
Romkin © (2007-11-15 17:33) [311]
> 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], когда о финализации просят позаботится окружение, виртуальная машина же есть?
← →
Юрий Зотов © (2007-11-15 17:38) [312]> Piter © (15.11.07 17:21) [305]
Миша, как ты наверняка знаешь, я человек крайне вежливый, поэтому не могу не отвечать на посты, прямо мне адресованные. Поэтому, если ты хочешь, чтобы я на них не отвечал, то ты их просто не пиши, ладно?
А уж если пишешь, то хотя бы разберись сначала, почему бывают такие программы, что если ее запустить сто раз (каждый раз завершая), то на сто первый окажется, что ресурсы системы кончились. А еще разберись с тем, почему после срубания программы, юзающей Paradox"овскую БД, коннект к этой БД окажется невозможным. А еще разберись с тем, почему бывает невозможно удалить файл, хотя программа, которая его юзала, уже завершилась.
Короче, разберись с тем, что такое освобождение ресурсов. Или не спорь.
← →
Reindeer Moss Eater © (2007-11-15 17:38) [313]С философской точки зрения все просто.
Если ресурсы в ява приладе остались неосвобожденными, то надо привлечь к ответственности ИИ (сборщик мусора), а программист не виноват.
:)
← →
Piter © (2007-11-15 17:39) [314]@!!ex © (15.11.07 17:23) [307]
Ответьте на [282]?
а что там отвечать? Это логика программиста на native-языке, привыкшего работать напрямую с памятью, с байтами, битами
reonid © (15.11.07 15:18) [282]
Проблема в том, что у каждого класса, никаких ресурсов не использующих,
может быть потомок, которому нужны для внутреннего
функционирования какие-нибудь нетривиальные ресурсы
не должно быть у класса никаких нетривиальных ресурсов, которые не сможет убрать сборщик мусора.
Я продолжу это логику, попытаюсь провести параллель. С тем же успехом можно заявить:"У каждого класса может быть потомок, который захочет напрямую взаимодействовать с видео-картой. Совершщенно у любого.
И что тогда? Или писать в документации класса
"Потомкам класса запрещается напрямую работать с видео-картой?".
И это чистая правда. Да, может быть такой потомок и будет, но мы почему-то привыкли к стандартным ограничениям windows, мы приемлем прослойку в виде драйвера и более того набора специальных функций DirectX для работы с графикой. Но почему-то ограничения языка с автоматической сборкой мусора мы не приемлем и прослойку в виде java-машины отторгаем. А почему? А потому что не привыкли.
Я уверен, что с появлением Windows тысячи программистов занимающихся разработками игр плевались, когда им захотели запретить напрямую работать с видеокартами. А сейчас ничего, без существующей иерархии и представить что-то сложно работающее в 3D.
← →
Piter © (2007-11-15 17:42) [315]Romkin © (15.11.07 17:25) [308]
Piter © (15.11.07 17:21) [305] Хм. Тогда зачем в java сборщик мусора?
на такой незатейливый вопрос у меня есть только один незатейливый ответ:
"чтобы собирать мусор" ;)
← →
Romkin © (2007-11-15 17:44) [316]Piter © (15.11.07 17:39) [314]
> не должно быть у класса никаких нетривиальных ресурсов,
> которые не сможет убрать сборщик мусора.
О как!
Юра, помнишь, ты код с Stream приводил? Так вот: метод close ты вызывать не должен был! Нет у этого класса никаких ресурсов, которые не уберет сборщик мусора!
← →
Юрий Зотов © (2007-11-15 17:45) [317]> Piter © (15.11.07 17:39) [314]
> не должно быть у класса никаких нетривиальных ресурсов, которые не
> сможет убрать сборщик мусора.
Миша, ну я тебя умоляю - помолчи. Пойми - сейчас над тобой уже просто смеяться начнут. Ты даже не представляещь, сколько откровенной чуши ты уже тут наморозил...
← →
DiamondShark © (2007-11-15 17:48) [318]
> reonid © (15.11.07 15:18) [282]
>
> Проблема в том, что у каждого класса, никаких ресурсов не
> использующих,
> может быть потомок, которому нужны для внутреннего
> функционирования какие-нибудь нетривиальные ресурсы.
> Совершенно у любого.
Во-первых, это неверно. Есть куча базовых классов, у которых использование нетривиальных ресурсов может присниться только в страшном сне. Так что не у любого, а у некоторых. Так точнее.
Во-вторых, давайте будем разбираться, что это могут быть за ресурсы, и откуда они возьмутся.
Обычно у ресурсов есть некое внешнее имя (путь для файла, сетевой адрес для сокета, строка подключения для бдконнекта, ID устройства для аудиомикшера и т.п.), это естественно, т.к. для того, чтобы захватить ресурс его надо сначала как-то идентифицировать.
Являются ли имена ресурсов жестко зашитыми в коде класса? Если да, то это плохой класс: тупой, непереносимый, накладывающий неоправданные ограничения на окружение. Вообще, я слабо представляю себе полезность класса, работающего с файлом с жестко заданным именем, или с жестко заданным сетевым адресом и т.п.
Значит, классу должны быть переданы имена (идентификаторы) ресурсов. Стоп. А зачем передавать имена? Гораздо лучше передать объект-обёртку для какого-то ресурса. Причём, объект самого абстрактного типа, насколько возможно, например, абстрактный стрим вместо файла. Это увеличит гибкость класса, расширит область его возможного применения. Посмотрите на имеющиеся библиотеки: именно так очень часто и делают.
Таким образом, владеть нужными ресурсами объекту вовсе даже не обязательно, можно только ссылаться.
Конечно, может объекту понадобятся какие-то ресурсы для временного использования. Такие надо использовать по принципу открыл-поюзал-закрыл в месте непосредственной надобности.
В общем, в подавляющем большинстве я не вижу случаев, не укладывающихся в две вышеозначенные стратегии.
Конечно, один раз на тысячу может попасться какой-либо совсем нетривиальный случай. По-человечески я сочувствую столкнувшемуся с ним разработчику, но это не повод считать упавшие боинги.
← →
Игорь Шевченко © (2007-11-15 17:51) [319]Юрий Зотов © (15.11.07 17:26) [310]
> Разработчик некоего класса ведь не просто так объявил их
> виртуальными - тем самым он дал возможность разработчикам
> возможных потомков модифицировать их поведение
А если не объявил ?
> Игорь, ты смотришь на класс, как его юзер, как прикладник.
> И с этой точки зрения тебе по барабану, позаботился этот
> класс о своих потомках, или нет. Но как только ты начнешь
> писать этих самых потомка, так тебе это тут же станет вовсе
> не безразлично.
Вот! В свое время, в момент выхода первых версий Delphi народ очень возмущался - а чего это в VCL слишком много полей объявлено, как private - когда надо почесать левой ногой правое ухо, совсем не получается такое чесание. Даже мода была писать свои классы, объявляя чуть ли все содержимое минимум protected, ну а методы, натурально, виртуальными - а вдруг кому-то понадобится доступ, а вот и он, как на ладони.
А потом, знаешь ли, привыкли чесать уши так, как дядя Фрэнк Борланд разрешает чесать, потому как дело делать надо и желательно без дополнительных путей для ошибок. И в своих классах стали разграничивать уровень доступа и то, что не должно быть виртуальным, не стали делать виртуальным.
А что до деструкторов - то, насколько мне известно, программисты каждой строке в Delphi в конце работы с ней не присваивают пустое значение, освобождая ейную память. И в голову наверное им не приходит, потому как знают, что RTL вкупе с компилятором сама о строках позаботится.
Ну и со сброкой мусора тоже самое.
← →
Romkin © (2007-11-15 17:51) [320]
> А зачем передавать имена? Гораздо лучше передать объект-
> обёртку для какого-то ресурса. Причём, объект самого абстрактного
> типа, насколько возможно, например, абстрактный стрим вместо
> файла. Это увеличит гибкость класса, расширит область его
> возможного применения. Посмотрите на имеющиеся библиотеки:
> именно так очень часто и делают.Таким образом, владеть
> нужными ресурсами объекту вовсе даже не обязательно, можно
> только ссылаться.
Продолжи мысль пожалуйста.
1. Где мне взять этот объект-обертку.
2. Ну ссылаюсь я на него, дальше что?
Страницы: 1 2 3 4 5 6 7 8 9
10 11 вся ветка
Форум: "Прочее";
Текущий архив: 2007.12.16;
Скачать: [xml.tar.bz2];
Память: 1.11 MB
Время: 0.106 c