Форум: "Прочее";
Текущий архив: 2007.12.16;
Скачать: [xml.tar.bz2];
Вниз
delphi = pascal = языки для начинающих Найти похожие ветки
← →
Kick (2007-11-13 19:36) [0]так препод сказал.. Сказал что будем учить java.
← →
@!!ex © (2007-11-13 19:42) [1]Преподы - обычно в порграммирование не разбираются, ибо не учавствуют в реальных проектах, и не знаю существующих реалий.
так я сказал.
← →
Правильный_Вася (2007-11-13 19:47) [2]ну и учи
одно другому не мешает
← →
ferr (2007-11-13 19:49) [3]java то ещё проще =)
← →
Anatoly Podgoretsky © (2007-11-13 19:52) [4]> Kick (13.11.2007 19:36:00) [0]
Будешь крут, вместе с предподавателем!
← →
AlexWlad © (2007-11-13 19:53) [5]А как называется курс? Java-программирование? Или что-то более общее? И вообще: "учить программированию" <> "учить языкам программирования".
← →
qack (2007-11-13 19:53) [6]Delphi - это среда.
← →
Kick (2007-11-13 19:54) [7]Да я сам с этим не согласен. Просто не понимаю по каким причинам он так говорит.
← →
Johnmen © (2007-11-13 19:55) [8]
> qack (13.11.07 19:53) [6]
> Delphi - это среда.
Ты тоже учи яву - будешь крут.
← →
Virgo_Style © (2007-11-13 19:56) [9]Когда говорят, что pascal создавался для обучения и поэтому непригоден для реальных проектов, я хотя бы вижу логику.
Когда говорят, что pascal прост, поэтому мы будем учить сложное... хм. Бог в помощь! (с)
← →
Johnmen © (2007-11-13 19:56) [10]
> Просто не понимаю по каким причинам он так говорит.
Ага. На этом сайте он и отвечает.
← →
@!!ex © (2007-11-13 19:57) [11]> [7] Kick (13.11.07 19:54)
Это общее заблуждение.
Я тоже так считал, пока не понял, что все зависит только от проггера, но не от языка.
← →
Kick (2007-11-13 19:59) [12]
> Delphi - это среда.
Всем давно извсетно что начиная с delphi 7 язык delphi.
← →
Kick (2007-11-13 20:02) [13]
> А как называется курс? Java-программирование? Или что-то
> более общее? И вообще: "учить программированию" <> "учить
> языкам программирования".
Java-программирование - что-то типа этого.
Я понимаю что после таких курсов реальных знаний не получишь.
Типа типы данных пройдем, основыне конструкции языка и т.д. Но как это поможет решать реальные задачи?
← →
Jieshua (2007-11-13 20:13) [14]Kick
В случае java, язык, это фигня. Вся сила java в ее стандартной библиотеке, которая поистине бездонна. Но весть этот балласт не всегда нужен, поэтому правильные адепты используют C++.
Изучив java, гораздо легче обратиться в С++, чем изучив паскаль. Почему С++? Поймешь когда обратишься. Ибо в С++ истина. Да не угаснет слава Его во веки веков. Да прибудет с нами Страуструп и template, пророк его.
Аминь.
← →
Johnmen © (2007-11-13 20:27) [15]Ну вот и бред пошёл...
← →
Юрий Зотов © (2007-11-13 20:27) [16]Препод сказал, что delphi и pascal - языки для начинающих, поэтому он будет учить начинающих джаве.
Дурак ваш препод.
← →
Юрий Зотов © (2007-11-13 20:28) [17]Кстати, если уж говорить о джаве, то это вообще язык для детского сада.
← →
Rouse_ © (2007-11-13 21:25) [18]Любой язык - это просто язык. Дурак будет он, если учить будет языку, а не алгоритмике. А алгоритмика - она в отличие от языков и крутости своей - кроссплатформенна :)
← →
@!!ex © (2007-11-13 21:28) [19]"Говорить, что жава круче, потому что кроссплатформенна,
тоже самое, что говорить что анальный секс лучше, потому что применим к обоим полам." (С) БОР
← →
KilkennyCat © (2007-11-13 21:28) [20]
> Rouse_ ©
+100
← →
oxffff © (2007-11-13 21:28) [21]
> Юрий Зотов © (13.11.07 20:27) [16]
> Юрий Зотов © (13.11.07 20:28) [17]
Тише, тише, Юрий Зотов.
Что вы так горячитесь.
Это же провокация.
← →
sniknik © (2007-11-13 21:41) [22]> Это же провокация.
это очевидно
на вопрос "А как называется курс?" ответ
> Java-программирование - что-то типа этого.
? студент да чтоб не знал что изучает. а цвет учебника ему интересно известен?
← →
Piter © (2007-11-13 21:42) [23]это все равно, что говорить русский язык лучше английского или наоборот. Или что windows лучше linux. Люди, которые так говорят, на 90% ничего другого просто не знают.
← →
Kostafey © (2007-11-13 21:47) [24]> [1] @!!ex © (13.11.07 19:42)
> Преподы - обычно в порграммирование не разбираются, ибо
> не учавствуют в реальных проектах, и не знаю существующих
> реалий.
> так я сказал.
+10
> [14] Jieshua (13.11.07 20:13)
:)
> [16] Юрий Зотов © (13.11.07 20:27)
> Препод сказал, что delphi и pascal - языки для начинающих,
> поэтому он будет учить начинающих джаве.
>
> Дурак ваш препод.
А все обучение таково.
Даже на курсах подготовки к сдаче сертификации
учат азам.
Программированию научить вообще, ИМХО, невозмжоно.
> [17] Юрий Зотов © (13.11.07 20:28)
> Кстати, если уж говорить о джаве, то это вообще язык для
> детского сада.
Прошу аргументировать замечание.
← →
DVM © (2007-11-13 22:09) [25]
> Kick
Препода фамилия не на букву Ф ?
← →
Юрий Зотов © (2007-11-13 22:22) [26]> Kostafey © (13.11.07 21:47) [24]
Пишем класс, наследник Object. В процессе своей работы класс захватывает некие ресурсы, отличные от памяти. Предлагается указать место, где класс должен эти ресурсы освободить.
← →
Kostafey © (2007-11-13 22:36) [27]> [26] Юрий Зотов © (13.11.07 22:22)
> Пишем класс, наследник Object. В процессе своей работы класс
> захватывает некие ресурсы, отличные от памяти. Предлагается
> указать место, где класс должен эти ресурсы освободить.
Кхм... затрудняюсь ответить.
← →
)) (2007-11-13 22:51) [28]
> Предлагается указать место, где класс должен эти ресурсы
> освободить.
Неужели в 17-й строке ?
← →
Юрий Зотов © (2007-11-13 23:02) [29]> Kostafey © (13.11.07 22:36) [27]
Вдобавок: отсутствие указателей и средств прямого управления памятью, автоматический подсчет ссылок и сборка мусора - все это, конечно, позволяет програмисту уделить большее внимание решению прикладной задачи и подстраховывает его от ошибок. Но, с другой стороны, лишает его мощных возможностей, предоставляемых хоть теми же указателями.
Для программиста начинающего важнее первое (все равно пользоваться указателями он, как правило, толком не умеет). Для программиста опытного важнее второе (а ошибок управления памятью он уж как-нибудь и сам не допустит). Почему я и говорю - язык хорош для детского сада, но плох для профи.
← →
Kostafey © (2007-11-13 23:09) [30]> [29] Юрий Зотов © (13.11.07 23:02)
Осмелюсь лишь предположить, что,
возможно, ручное управление памятью
было изъято из языка не только исходя
из требований безопасности, но и по
техническим причинам, т.е. речь уже
идет не о физической памяити, а о некоей
виртуальной памяти, выделяемой JVM.
Но в целом должен сказать, что
теперь я принял вашу точку зрения.
← →
celades © (2007-11-13 23:14) [31]
> Почему я и говорю - язык хорош для детского сада, но плох
> для профи.
почему-то профи как раз самые его большие евангелисты.
← →
Anatoly Podgoretsky © (2007-11-13 23:16) [32]П. Дети, с нового семестра мы изучаем язык.
С. А какой,
П. Иностранный (с гордостью).
← →
Юрий Зотов © (2007-11-13 23:19) [33]> Kostafey © (13.11.07 23:09) [30]
Вот уже года полтора пишу на джаве. Ощущение такое, что после гоночного велосипеда сел на трехколесный. Вроде бы, тоже едет, но как-то не очень...
:о)
← →
Юрий Зотов © (2007-11-13 23:21) [34]> celades © (13.11.07 23:14) [31]
Видимо, не все.
:о)
← →
Kostafey © (2007-11-13 23:24) [35]> [33] Юрий Зотов © (13.11.07 23:19)
> Вот уже года полтора пишу на джаве.
А вы на каких Java-форумах бываете,
а то на этом форуме не совсем отвечающие
тематике вопросы получаться? :)
← →
Zeqfreed © (2007-11-13 23:24) [36]> Piter © (13.11.07 21:42)
Разумеется английский и Линукс лучше. Какие тут вопросы могут быть :)
← →
Юрий Зотов © (2007-11-13 23:30) [37]> Kostafey © (13.11.07 23:24) [35]
А я на них практически не бываю. Оригинальная документация от Sun, IBM и производителей библиотек - этого, как правило, достаточно. А когда недостаточно - есть гугль.
← →
Kostafey © (2007-11-13 23:34) [38]> [37] Юрий Зотов © (13.11.07 23:30)
Чем собственно и пользуюсь.
Всего этого читать - не перечитать.
← →
Petr V. Abramov © (2007-11-13 23:53) [39]> так препод сказал.. Сказал что будем учить java.
А в Вашем учебном заведении каждый препод д-чит, как он хочет, или все-таки в соответствии с учебным планом? Или до вас веяние, что у нас все-таки "управляемая демократия", еще не дошло?
Или у нас уже появились СПТУ-JAVA № 28?
← →
Плохиш © (2007-11-14 00:18) [40]
> Юрий Зотов © (13.11.07 23:30) [37]
> > Kostafey © (13.11.07 23:24) [35]
>
> А я на них практически не бываю. Оригинальная документация
> от Sun, IBM и производителей библиотек - этого, как правило,
> достаточно. А когда недостаточно
Мне в этом случае знания делфи и справка по делфи 7 очень помогала :-)
Искал с полтора года назад причину неадекватности обработки нажатий кнопок в java-проги, написаной java-программистом, так там вместо того, чтобы сказать, что обрабатывать нажатие кнопки дальше не надо, установкой key в 0, такое наварочено было 8-O
← →
Германн © (2007-11-14 01:43) [41]
> Юрий Зотов © (13.11.07 23:19) [33]
>
> > Kostafey © (13.11.07 23:09) [30]
>
> Вот уже года полтора пишу на джаве. Ощущение такое, что
> после гоночного велосипеда сел на трехколесный. Вроде бы,
> тоже едет, но как-то не очень...
> :о)
>
Ну у тебя хватило ума чтобы использовать детский трёхколёсный как самокат, потому он всё-таки едет. А некоторые и с этим не справляются, поскольку пытаются ехать сидя на сиденьи(седле) и крутя педали.
:-)
← →
Marser © (2007-11-14 01:55) [42]
> Delphi - это среда.
А я думаю, что Delphi это тяпница! Ибо также приятна! :-))
← →
Германн © (2007-11-14 02:02) [43]
> Marser © (14.11.07 01:55) [42]
>
>
> > Delphi - это среда.
>
> А я думаю, что Delphi это тяпница! Ибо также приятна! :-
> ))
>
Т.е. приятна, когда её выключаешь? :-)
← →
Marser © (2007-11-14 02:07) [44]А если честно, то меня в Яве всё-таки больше всего завораживает кросс-платформенность. А недостатки, описанные ЮЗ - так а разве в С# не та же история? Се путь интерпритируемых языков, использующих виртуальную машину.
Помнится, то ли в конце 2004, то ли в начале 2005 сидели мы в Киеве с Deep"ом, Пашей и Andrey"ем (его здесь только старожилы могут помнить, это "дремучая " тусовка) и Витя мне говорил о .NET и о том, что всё идёт к тому, чтобы шаловливые ручки программиста ограничивать от засовывания куда не следует, что оттуда и .NET и Java, и очень мне запомнилось, что я тогда ещё агрессивно плевался и грозился, что свалю в embedded.
Прошло почти три года. Всё это время я работал, сперва студентом, а сейчас уже и полноценно. Не под руководством опытного наставника, а, как правило, впереди паровоза, там, где окружающие мало чем могли помочь.
И вот что совсем уж странно, теперь я бы так громко не плевался. Романтический подход умер, что ли...
← →
Marser © (2007-11-14 02:08) [45]
> Германн © (14.11.07 02:02) [43]
>
>
> > Marser © (14.11.07 01:55) [42]
> >
> >
> > > Delphi - это среда.
> >
> > А я думаю, что Delphi это тяпница! Ибо также приятна!
> :-
> > ))
> >
>
> Т.е. приятна, когда её выключаешь? :-)
Да нет... Приятно работать :-)
Конечно, в D2006 уже не совсем то, что в D6-7, но всё-таки :-)
← →
Piter © (2007-11-14 02:09) [46]Юрий Зотов © (13.11.07 23:02) [29]
Вдобавок: отсутствие указателей и средств прямого управления памятью, автоматический подсчет ссылок и сборка мусора - все это, конечно, позволяет програмисту уделить большее внимание решению прикладной задачи и подстраховывает его от ошибок. Но, с другой стороны, лишает его мощных возможностей, предоставляемых хоть теми же указателями.
Для программиста начинающего важнее первое (все равно пользоваться указателями он, как правило, толком не умеет). Для программиста опытного важнее второе (а ошибок управления памятью он уж как-нибудь и сам не допустит). Почему я и говорю - язык хорош для детского сада, но плох для профи
именно поэтому наверное в той же гребанной америке это язык по популярности номер 1, да?
Юрий Зотов © (13.11.07 23:02) [29]
а ошибок управления памятью он уж как-нибудь и сам не допустит
ну да, конечно... В любом серьезном проекте есть ошибки, связанные с памятью, абсолютно в любом. Да, у грамотных программеров не будет ошибок типичных, элементарных, но в целом они будут. Пример? Да операционная система windows, ведь точно ее писали не лохи, а ошибок множество, в том числе по управлению памятью. И еще больше не найденных. Да, может быть они проявятся при определенных обстоятельствах раз в 10 лет, но все равно это ошибка.
Так что за автоматизацией будущее, языки будут все навороченее и все больше делать за программиста, стандартные приемы, стандартные классы, все больше будет ламеров типа "программистов", но и серьезным дядям все проще будет работать, как ни крути... Таков прогресс, он всегда идет вперед, хотя кому-то это и не нравится.
← →
Германн © (2007-11-14 02:16) [47]
> Marser © (14.11.07 02:08) [45]
> Конечно, в D2006 уже не совсем то, что в D6-7, но всё-таки
> :-)
Лично для меня, BDS2006 - это "вообще не то". Наверно в душе я - консерватор. :-)
Или "суперстар" :-)
← →
Marser © (2007-11-14 02:20) [48]
> Piter © (14.11.07 02:09) [46]
IMHO, ЮЗ это всё понимает не хуже твоего. Правого в этом споре нет, а занятые стороны - условности, ну, может возрастное, у обоих, причём :-))
Всё же "величие истинного пути" не в выборе среды и болтологии по поводу её преимуществ, а в наилучшей реализации поставленной задачи в имеющихся условиях (во задвинул, по-военному :-)) )
> Германн © (14.11.07 02:16) [47]
Тёзка, верите, нет? Сам бы ни за какие коврижки не перешёл! :-)
← →
Германн © (2007-11-14 02:39) [49]
> > Германн © (14.11.07 02:16) [47]
>
> Тёзка, верите, нет? Сам бы ни за какие коврижки не перешёл!
> :-)
>
Дык а какие у меня основания не верить? Верю конечно (Давно здесь сидим:). "Заставили гады перейти".
А я и не переходил и не собираюсь. Мои проекты как были в Д4 и Д6, так там и остались.
Наверно те коврижки продаются мне и тебе по разной цене. :-)
← →
Черный Шаман (2007-11-14 05:35) [50]
> Юрий Зотов © (13.11.07 23:02) [29]
>
> > Kostafey © (13.11.07 22:36) [27]
>
>
> Для программиста начинающего важнее первое (все равно пользоваться
> указателями он, как правило, толком не умеет). Для программиста
> опытного важнее второе (а ошибок управления памятью он уж
> как-нибудь и сам не допустит). Почему я и говорю - язык
> хорош для детского сада, но плох для профи.
Для индусов еще очень хорош. С Java термин "стадо программистов" приобретает довольно практичный смысл.
← →
@!!ex © (2007-11-14 07:42) [51]> [47] Германн © (14.11.07 02:16)
Я думал я один такой... :)
У меня до сих пор Д7.
ХОтя на работе и приходится под БДС компилировать.
← →
Gydvin © (2007-11-14 07:53) [52]Д7 - Д6 вообще класика )
И помоему самая удачная реализация среды.
а на БСД 2006 (у меня турбо эксплорер) чета вообще нет никого желания переходить
← →
Eraser © (2007-11-14 11:05) [53]
> Gydvin © (14.11.07 07:53) [52]
и не надо. нужно переходить на delphi 2007.
приемуществ, по сравнению с D7, множество. Как в редакторе кода, так и в батонокидательстве.
← →
boa_kaa © (2007-11-14 11:56) [54]
> Marser © (14.11.07 02:07) [44]
> А недостатки, описанные ЮЗ - так
> а разве в С# не та же история?
Не та же. Причем совершенно не та же.
← →
Kolan © (2007-11-14 11:59) [55]> delphi = pascal = языки для начинающих
Начать надо с того, чтоdelphi <> pascal
← →
Rouse_ © (2007-11-14 12:01) [56]
> именно поэтому наверное в той же гребанной америке это язык
> по популярности номер 1, да?
В штатах обьем кода мал - там народ давно на индусов переключился :)
← →
Игорь Шевченко © (2007-11-14 12:04) [57]Visual Basic надо учить. Ибо.
← →
Студент (2007-11-14 12:06) [58]Да ацтой ваш delphi, у него кросс-платформенности нет. И шаблонов.
← →
Юрий Зотов © (2007-11-14 12:07) [59]> Piter © (14.11.07 02:09) [46]
Миш, научись спорить конкретно. Или не спорь совсем.
Тебе приводят конкретные факты - а в ответ, извини, словоблудие. В лучшем случае - псевдоаргументы, к сути напрямую не относящиеся.
Несерьезно.
← →
Ega23 © (2007-11-14 12:10) [60]
> @!!ex © (14.11.07 07:42) [51]
>
> > [47] Германн © (14.11.07 02:16)
>
> Я думал я один такой... :)
> У меня до сих пор Д7.
У меня D7. И не стремлюсь менять.
← →
isasa © (2007-11-14 12:31) [61]Студент (14.11.07 12:06) [58]
Да ацтой ваш delphi, у него кросс-платформенности нет. И шаблонов.
Ага, ага. А мы сразу пытаемся объять необъятное. Один раз написал и затих.
Универсальным только понос бывает ... :)
← →
isasa © (2007-11-14 12:34) [62]Да, как всегда, забыл. А в универсальной Java когда речь заходит о соединении с сервером(да тем же браузером с бизнес слоем), так сразу универсальность пропадает и выясняется, что IBM сервера вижу, Sun Application Server не вижу.
← →
Azize © (2007-11-14 12:42) [63]delphi - это хорошо
java -ещё лучше
Но самый крутой язык - Ассемблер
Порекомендуй преподу
← →
Marser © (2007-11-14 13:02) [64]
> boa_kaa © (14.11.07 11:56) [54]
> > Marser © (14.11.07 02:07) [44]> А недостатки, описанные
> ЮЗ - так > а разве в С# не та же история?Не та же. Причем
> совершенно не та же.
Весь внимание.
← →
TUser © (2007-11-14 13:03) [65]А я вот думаю, что препод должен учить тому языку, который он сам знает в совершенстве. Потому что Delphi или Java могут быть хороши и замечательны, но нет ничего хуже препода, который в этом не разбирается. Может твой препод - Java-ас.
← →
Юрий Зотов © (2007-11-14 13:21) [66]> TUser © (14.11.07 13:03) [65]
Если он Java-ас, то не разбираться в Delphi он просто не может.
← →
TUser © (2007-11-14 13:23) [67]Также надо заметить, что у МС давно есть очень дешевые лицензии на VS для образовательных учереждений (гораздо дешевле борландовских). А Ява - всегда была бесплатной. И появление Turbo Delphi, разумеется, не означает мгновенного переписывания сложившихся программ ради такого хорошего Паскаля.
← →
DiamondShark © (2007-11-14 13:35) [68]
> Почему я и говорю - язык хорош для детского сада, но плох
> для профи.
Если "профи" определить как "лицо, склонное к половым перверсиям", то таки да, для такого язык типа Ц++ в самый раз. При развитой фантазии он и с Паскалем найдёт себе немало приятных минут.
А вообще, что вы хотите от жабы. Угребанская реализация стыренных у Вирта с Францем идей.
← →
DiamondShark © (2007-11-14 13:39) [69]
> Юрий Зотов © (13.11.07 22:22) [26]
>
> Пишем класс, наследник Object. В процессе своей работы класс
> захватывает некие ресурсы, отличные от памяти. Предлагается
> указать место, где класс должен эти ресурсы освободить.
А можно встречный вопрос: а где в описании языка написаны слова "автоматическое управление ресурсами, отличными от памяти"?
Метод Close и интерфейс IDisposable вам в руки.
← →
DiamondShark © (2007-11-14 13:47) [70]
> а ошибок управления памятью он уж как-нибудь и сам не допустит
ПлакалЪ.
Посмотрите любые списки уязвимостей, и сосчитайте количество дырок типа "arbitrary code execution".
Единственной причиной их наличия является то, что супер-пупер профи, пользуясь сами-знаете-каким языком для настоящих супур-пупер профи, "как-нибудь не допускают" ошибок управления памятью.
← →
Юрий Зотов © (2007-11-14 14:11) [71]> DiamondShark © (14.11.07 13:39) [69]
1. А можно тоже встречный вопрос: а где я говорил об "автоматическом управлении ресурсами, отличными от памяти"? Говорилось как раз о ручном и предлагалось указать место, куда нужно прописать их освобождение. И... этта... нельзя ли читать повнимательнее?
2. Метод Close у класса Object я найти не смог (а мы писали потомок Object, напоминаю). И никакой другой метод класса Object, вызываемый перед разрушением объекта, я тоже найти не смог.
3. Насчет интерфейса IDisposable - метод Close я у него тоже найти не смог (есть метод dispose, который относится к классам графического интерфейса о котором см. ниже). Может, не в том интерфейсе искал? Можно привести его полное имя, вместе с пакетом? И если этот пакет - не java.lang.*, а любой другой, то еще пара встречных вопросов:
а. А где в описании языка упоминается интерфейс IDisposable?
б. Есть такой классpublic class MyObject /*extends Object*/ implements IDisposable {
public void dispose() {
...
}
}
А есть гарантия, что метод dispose будет вызван перед разрушением объекта? Только прежде, чем отвечать, обратите внимание на предка.
← →
DiamondShark © (2007-11-14 14:30) [72]
> Юрий Зотов © (14.11.07 14:11) [71]
Метод Close надо написать ручками.
Не пойму, в чём проблема. Если вы работаете с unmanaged ресурсами, то и пишите их освобождатели сами, абсолютно точно так же, как в любом другом языке.
← →
Palladin © (2007-11-14 14:36) [73]Не знаю как Юрий, но мне психологически трудно работать с ЯП с GC, жесткое правило старой закалки: создал - уничтожь, не дает покоя, дискомфортно как то себя чувствую :) что кто то за меня будет подбирать...
и привычка (может быть уже и вредная) освобождать внешние ресурсы именно в деструкторе, а не обвешивать логику класса двойной оберткой
конструктор
взятие ресурсов
освобождение ресурсов
деструктор
← →
Юрий Зотов © (2007-11-14 14:50) [74]> DiamondShark © (14.11.07 14:30) [72]
Насколько я понимаю, вопрос в IDisposable отпал. ОК, идем дальше.
> Метод Close надо написать ручками.
Хоть тремя ручками - а вызывать его будет Пушкин?
> пишите их освобождатели сами
Не вопрос. А вызывать эти освобождатели будет тоже Пушкин?
> точно так же, как в любом другом языке.
А вот и не точно так же. В "другом" (известно, каком) языке у любого объекта есть деструктор, который гарантированно вызывается перед разрушением любого объекта и в котором я могу гарантированно освободить любые захваченные объектом ресурсы. А теперь (внимание, вопрос!) - покажите мне то место в любом объекте java, где я могу гарантированно освободить любые ресурсы, захваченные этим объектом, например, в своем конструкторе.
← →
DiamondShark © (2007-11-14 15:05) [75]
> Юрий Зотов © (14.11.07 14:50) [74]
> Насколько я понимаю, вопрос в IDisposable отпал
Неужели документация под руку попалась?
> ...Пушкин?
> ...Пушкин?
Вы объясните внятно, в чём суть претензии, и к кому/чему она адресована.
> и в котором я могу гарантированно освободить любые захваченные объектом ресурсы
Дык, а код освобождения в деструкторе за вас гарантировано напишет Пушкин?
Какая принципиальная разница, напишите вы этот код в деструкторе, или в спец. методе Close?
> мне то место в любом объекте java, где я могу гарантированно
> освободить любые ресурсы
IDisposable.dispose -- при попадании объекта под сборку мусора
Свой Close-подобный метод для детерминированного освобождения там где душа пожелает.
← →
Юрий Зотов © (2007-11-14 15:35) [76]> DiamondShark © (14.11.07 15:05) [75]
> Неужели документация под руку попалась?
Нет, просто Вы проигнорировали оба моих вопроса по IDisposable и я это, естественно, понял так, что ответов на них у Вас нет.
> код освобождения в деструкторе за вас гарантировано напишет Пушкин?
Нет, Пушкин гарантированно вызовет деструктор. Большего от него и не требуется.
> IDisposable.dispose -- при попадании объекта под сборку мусора
> Свой Close-подобный метод для детерминированного освобождения
> там где душа пожелает.
Вот только что запустил Eclipse и попытался это сделать. Не получилось. Не могли бы Вы привести конкретный код непосредственного потомка Object, один из методов которого вызывается при попадании объекта под сборку мусора?
А я пока процитирую одну статеечку
( http://www.statmod.ru/3-5/programming/csharp_potapov/index.htm )
"Разработчики C# сочли этот метод настолько эффективным и удобным, что он поддерживается на уровне языка — посредством реализации интерфейса IDisposable. (Java такого механизма не имеет.)".
И задам вопрос - не путает ли кто-то из нас что-то?
← →
Skier © (2007-11-14 15:57) [77]а что тут спорить?
если "конечная цель" програмера сорваться на Запад, то Java ему очень
пригодится. :)
← →
Черный Шаман (2007-11-14 16:06) [78]
> Юрий Зотов © (14.11.07 14:11) [71]
>
> > DiamondShark © (14.11.07 13:39) [69]
>
> 1. А можно тоже встречный вопрос: а где я говорил об "автоматическом
> управлении ресурсами, отличными от памяти"? Говорилось как
> раз о ручном и предлагалось указать место, куда нужно прописать
> их освобождение. И... этта... нельзя ли читать повнимательнее?
>
Есть Object.finalize(), но он глючный
Вот только некоторые странные вещи, которые на первый взгляд могут не совпасть с нашим интуитивным представлением.
* Момент, когда вызовется метод finalize() четко не определен. На самом деле, в спецификации не гарантируется, что он воообще будет когда-нибудь вызван, даже если объект стал недостижим. Когда вызов может происходить зависит от реализации JVM.
* Метод finalize() не вызывает автоматически finalize() предка. Для того, чтобы это произошло, необходимо явно его вызвать: super.finalize().
* Метод finalize() будет вызван асинхронно, т.е. скорее всего в другом потоке. В текущей реализации Sun JVM для его обработки используется специальный поток "Finalizer", который последовательно вызывает финализаторы. Спецификация не ограничивает то, в каких потоках он может выполнятся или сколько может быть этих потоков. Единственное требование — это то, что этот поток не будет держать какую-нибудь блокировку. В одной из первых реализации JVM это разрешалось и приводило к странным эффектам.
* Ссылка на объект (this) доступна во время выполнения finalize(). Это означает, что потенциально объект может снова стать достижим. В этом случае метод finalize() никогда не будет вызван повторно.
* Объекты с нетривиальным методом finalize() обрабатываются сборщиком мусора особым образом. После того, как этот метод выполнился, сборщик мусора должен вновь определить что объект достижим. Это создает дополнительную нагрузку. Кроме того, в текущей реализации Sun JVM для поддержки используются дополнительные объекты FinalReference и Finalizer, что сказывается на объеме используемой памаять и производительности.
* То, что finalize() может исполняться в нескольких потоках параллельно, означает, что во многих случаях стоит позаботиться о синхронизации. В большинстве случаев нетривиальный метод finalize() будет использовать какие-либо разделяемые ресурсы.
* Порядок, в котором finalize() будет вызван не определен. Если у объекта A есть поле, которое ссылается на объект B и эти объекты стали недостижимы, то finalize() для A может быть вызван и до, после или одновременно с finalize() для B. Если B используется в finalize() для A, то его состояние во время выполнения не определено. Кроме того, это состояние может меняться во время выполнения finalize()!
* Спецификация не ограничивает, какие оптимизации могут применяться. Может так случиться, что finalize() будет вызван, после начала выполнения какого-либо метода, но но перед его завершением. Это иногда может стать проблемой, поскольку вызванный метод finalize() может невовремя изменить состояние поля объекта. Хорошим примером является 6295525.
← →
Romkin © (2007-11-14 16:11) [79]
> Есть Object.finalize(), но он глючный
Учитывая сказанное ниже, он не глючный. Он просто офигительно глюкавый!!!
← →
Юрий Зотов © (2007-11-14 16:23) [80]Чтобы уж совсем разобраться в этом вопросе. В джаве все объекты имеют метод finalize, про который в доке сказано вот что: "Called by the garbage collector on an object when garbage collection determines that there are no more references to the object. A subclass overrides the finalize method to dispose of system resources or to perform other cleanup".
Казалось бы, это и есть то самое место, которое я просил показать. Однако же, не все так просто. Пишем примерчик:
public class DisposableObject {
public DisposableObject() {
super();
System.out.println("created");
}
protected void finalize() throws Throwable {
System.out.println("finalized");
super.finalize();
}
}
И запускалку к нему:
public class Tester {
public static void main(String[] args) {
DisposableObject obj = new DisposableObject();
obj = null;
obj = new DisposableObject();
obj = null;
}
}
И вот что имеем в консоли:created
created
и ни разу заветного слова finalized. О как! У GC, оказывается, своя логика.
Итак, мы выяснили, что метод finalize либо не вызывается совсем (что прямо противоречит документации и является вопиюще бездарным глюком), либо GC может вызывать finalize не сразу после обнуления счетчика ссылок, а когда сочтет нужным (но тогда, увы, толку от finalized немного - например, я хочу повторно открыть файл, а он еще не закрыт, оказывается, хотя должен был).
===========================
Вопрос ко всем - Вы бы доверили свою жизнь автомобилю, который сам за Вас решает, когда, куда и с какой скоростью Вам ехать? Причем логика принятия им решения тоже не очень понятна.
И другой вопрос - а если программа с аналогичными "закидонами" управляет рабочим местом диспетчера аэропорта, то чем виноваты пассажиры в лайнере?
← →
Romkin © (2007-11-14 16:26) [81]А что такое throws Throwable ?
← →
DiamondShark © (2007-11-14 16:29) [82]
> Юрий Зотов © (14.11.07 15:35) [76]
Я действительно попутал. Нет такого в жабе.
Но Object.finalize() есть.
> Не могли бы Вы привести конкретный код непосредственного
> потомка Object, один из методов которого вызывается при
> попадании объекта под сборку мусора?
Object.finalize() перекройте. Только нафига дожидаться сборки мусора? Напишите свой метод освобождения unmanaged ресурсов, и вызывайте его детерминировано.
> Нет, Пушкин гарантированно вызовет деструктор. Большего
> от него и не требуется.
Это где это такое?
Единственный случай -- экземпляры на стеке в Ц++.
Для экземпляров на куче деструктор вызывается руками, оператором delete в Ц++ и явным вызовом деструктора в Дельфи.
Какая вам разница, в каком методе код освобождения размещать в деструкторе или в своём методе, если и то и другое надо явно вызывать?
И сформулируйте, наконец, свои претензии к языкам с автоматическим управлением памятью не в виде наводящих вопросов, а в повествовательных предложениях.
← →
Zeqfreed © (2007-11-14 16:31) [83]> Юрий Зотов © (14.11.07 16:23) [80]
А почему нельзя явно вызывать метод, освобождающий ресурсы, тогда, когда это необходимо?
← →
DiamondShark © (2007-11-14 16:31) [84]
> И другой вопрос - а если программа с аналогичными "закидонами"
> управляет рабочим местом диспетчера аэропорта, то чем виноваты
> пассажиры в лайнере?
Это не программа с закидонами.
Это програмер тупой.
← →
DiamondShark © (2007-11-14 16:32) [85]
> А почему нельзя явно вызывать метод, освобождающий ресурсы,
> тогда, когда это необходимо?
Потому что тогда нельзя будет тупо побычить на язык, который ниасилил патамучта GC.
← →
Zeqfreed © (2007-11-14 16:33) [86]> DiamondShark © (14.11.07 16:29) [82]
> Какая вам разница, в каком методе код освобождения размещать
> в деструкторе или в своём методе, если и то и другое надо
> явно вызывать?
Вот я этого тоже пока не понял. Не вижу принципиальной разницы. Возможно, Юрий смотрит куда-то глубже? :)
← →
Юрий Зотов © (2007-11-14 16:37) [87]> All
> Marser © (14.11.07 02:07) [44]
> в Яве всё-таки больше всего завораживает кросс-платформенность.
Тут, на форуме, не так давно человек задал вопрос: есть java-программа для мобилки, как запустить ее на PC?
И выяснилось... что нужен эмулятор!
LOL.
=================
Только не надо рассказывать про J2ME и J2SE, я это и сам знаю. Лучше давайте перестанем рассказывать про хваленую кроссплатформенность. Потому что под эмулятором можно и Delphi-программу где угодно запустить, был бы эмулятор. И будет такая же кроссплатформенность, ничуть не хуже.
← →
Юрий Зотов © (2007-11-14 16:42) [88]> DiamondShark © (14.11.07 16:32) [85]
Не хами. Это раз.
Если возникает вопрос, "почему нельзя явно вызывать метод, освобождающий ресурсы" - то марш учить ООП. Это два.
← →
Skier © (2007-11-14 16:43) [89]
> Потому что под эмулятором можно и Delphi-программу где угодно
> запустить, был бы эмулятор.
с этого места по-подробнее, пожалуйста.
← →
Reindeer Moss Eater © (2007-11-14 16:44) [90]> в Яве всё-таки больше всего завораживает кросс-платформенность.
А так же куча зачем-то написанных платформенно зависимых third party библиотек.
← →
Юрий Зотов © (2007-11-14 16:48) [91]> Romkin © (14.11.07 16:26) [81]
Это информация компилеру, что метод может возбудить исключение определенного класса (или нескольких классов, через запятую). Ежели метод с таким заголовком вызвать из в другого метода, то компилер потребует либо написать то же самое в заголовке этого другого метода, либо обработать исключения внутри него.
← →
Azize © (2007-11-14 16:50) [92]Предлагаю со спором что лучше перебраться сюда
http://delphimaster.net/view/15-1195048125/
← →
DiamondShark © (2007-11-14 17:02) [93]
> Юрий Зотов © (14.11.07 16:42) [88]
> Не хами. Это раз.
Я тебе не хамил, я констатировал факт.
> Если возникает вопрос, "почему нельзя явно вызывать метод,
> освобождающий ресурсы" - то марш учить ООП. Это два.
А, так тебя смущает, что получится, если во что-то вроде TObjectList напихать чего-то вроде TFileStream и отобрать возможность явно вызвать деструктор?
А кто тебе сказал, что программы, написанные на языках с явным управлением памятью должны переводиться на языки с GC дословным переводом?
← →
pasha_golub © (2007-11-14 17:05) [94]
> Юрий Зотов © (14.11.07 16:48) [91]
> Это информация компилеру, что метод может возбудить исключение
> определенного класса (или нескольких классов, через запятую).
>
А зачем? Это что за станция такая? Почему я не могу возбуждать произвольное исключение?
← →
Черный Шаман (2007-11-14 17:09) [95]
> Юрий Зотов © (14.11.07 16:37) [87]
>
> Только не надо рассказывать про J2ME и J2SE, я это и сам
> знаю. Лучше давайте перестанем рассказывать про хваленую
> кроссплатформенность. Потому что под эмулятором можно и
> Delphi-программу где угодно запустить, был бы эмулятор.
> И будет такая же кроссплатформенность, ничуть не хуже.
Не. Будет точно хуже. Так как эмулятор для мобилки есть, а Wine(ака эмулятор для Delphi) не очень то винит.
Для Java максимум нужно эмулировать Hal, а для Delphi всю операционку. Поэтому для перехода под Линукс с программы на Delphi часто выгоднее полностью переписать эту программу на Java или не переходить на Линукс.
Программы на Java я с бубнами на Линукс запущу, а большинство реальных программ написанных на .NET. Только не надо про Mono, видели, кушали, обляпались...
← →
Zeqfreed © (2007-11-14 17:10) [96]> pasha_golub © (14.11.07 17:05) [94]
Чтобы метод открытия файла не возбуждал исключения ошибки деления на нуль.
← →
Piter © (2007-11-14 17:16) [97]Юрий Зотов © (14.11.07 12:07) [59]
Миш, научись спорить конкретно. Или не спорь совсем.
Тебе приводят конкретные факты - а в ответ, извини, словоблудие
что не понравилось? Есть мнение, что в ОС Windows нет и не было участков кода, которые приводили / могли привести к утечке памяти?
Юрий Зотов © (14.11.07 15:35) [76]
Не могли бы Вы привести конкретный код непосредственного потомка Object, один из методов которого вызывается при попадании объекта под сборку мусора?
Юрий, а я не понял. Вы сетуете на то, что никакой метод не вызывается при сборке муссора. Ок, но ведь в том же Delphi тоже нет никакого метода, который вызывается при сборке мусора, поскольку там сборка мусора отсутствует.
Идем дальше... Если вы хотите именно дельфого подхода, ну так создавайте сами, уничтожайте тоже сами, можете даже соответствующему методу дать название Destroy для пущей "совместимости с Delphi".
Я правильно понял - вы ругаете Java за то, что там есть дополнительные возможности по сравнению с дельфи, но эти возможности не так хороши как хотелось бы. Поэтому делаем вывод, что дельфи лучше. Все верно?
← →
Черный Шаман (2007-11-14 17:16) [98]
> Zeqfreed © (14.11.07 17:10) [96]
>
> > pasha_golub © (14.11.07 17:05) [94]
>
> Чтобы метод открытия файла не возбуждал исключения ошибки
> деления на нуль.
Тю, я почти в каждом методе пишу
try
код метода с другими try
except
Logger.Log(..., E.message);
edn;
Ошибка не должна вылезти за метод обработки, но должна быть сохранена для изучения и устранения.
← →
Romkin © (2007-11-14 17:16) [99]
> А зачем? Это что за станция такая? Почему я не могу возбуждать
> произвольное исключение?
Тонкий вопрос :)
По видимому, нет централизованного места обработки исключений...
← →
Romkin © (2007-11-14 17:17) [100]
> Ошибка не должна вылезти за метод обработки, но должна быть
> сохранена для изучения и устранения.
Мама, роди меня обратно...
← →
@!!ex © (2007-11-14 17:18) [101]> Так как эмулятор для мобилки есть, а Wine(ака эмулятор для
> Delphi) не очень то винит
Хм. Странно. Мой проект с использованием OpenGL 2.0(шейдеры, VBO, мультитекстуринг) + FMod(объемный звук) + DevIL спокойно запсукается и работат со скоростью сравнимую с виндой.
← →
Канадец (2007-11-14 17:18) [102]
> DiamondShark © (14.11.07 16:29) [82]
> Единственный случай -- экземпляры на стеке в Ц++.
Это не совсем верно. Нормальные программисты в таких случаях используют auto_ptr и shared_ptr
← →
@!!ex © (2007-11-14 17:19) [103]> Юрий, а я не понял. Вы сетуете на то, что никакой метод
> не вызывается при сборке муссора. Ок, но ведь в том же Delphi
> тоже нет никакого метода, который вызывается при сборке
> мусора, поскольку там сборка мусора отсутствует.
Хм. в дельфе я всегда знаю, в какой момент будет удален объект.
а в яве?
← →
pasha_golub © (2007-11-14 17:20) [104]
> Zeqfreed © (14.11.07 17:10) [96]
>
> > pasha_golub © (14.11.07 17:05) [94]
>
> Чтобы метод открытия файла не возбуждал исключения ошибки
> деления на нуль.
>
Да ну блин?! А какое его (ее) дело, что я собираюсь возбудить? :)
> Черный Шаман (14.11.07 17:16) [98]
> Ошибка не должна вылезти за метод обработки, но должна быть
> сохранена для изучения и устранения.
Вопрос спорнейший. Это ежели так действовать, то мы должны из каждого метода еще и код возврата вернуть. Типа вышло али не вышло. А лог можно и на "верху" построить. Более того со стеком вызовов, и где шо упало. Живой пример EurekaLog.
А, извините, после вызова метода каждый раз его case"ами окружать для выяснения чего там с ним случилось внутре, это не дело. Хотя как вариант существует. Вон вся BDE таким макаром крутится. DBIResult тебе вернули, а ты уж будь добр выясняй.
← →
Zeqfreed © (2007-11-14 17:21) [105]В C++ тоже есть спецификация исключений. В принципе явную какую-то пользу от них вряд ли можно получить, но они могут выступать в качестве дополнительного самодокументирования кода.
← →
Zeqfreed © (2007-11-14 17:22) [106]> Да ну блин?! А какое его (ее) дело, что я собираюсь возбудить?
> :)
Это все вопросы этики :)
← →
Romkin © (2007-11-14 17:23) [107]
> Вопрос спорнейший. Это ежели так действовать, то мы должны
> из каждого метода еще и код возврата вернуть. Типа вышло
> али не вышло. А лог можно и на "верху" построить. Более
> того со стеком вызовов, и где шо упало. Живой пример EurekaLog.
> А, извините, после вызова метода каждый раз его case"ами
> окружать для выяснения чего там с ним случилось внутре,
> это не дело. Хотя как вариант существует. Вон вся BDE таким
> макаром крутится. DBIResult тебе вернули, а ты уж будь добр
> выясняй.
Это типичный подход, унаследованный от С, С++ и подобных языков с плохой поддержкой исключений. Передача статуса операции через результат функции. Некоторые никак не могут отвыкнуть...
← →
Черный Шаман (2007-11-14 17:25) [108]
>
> Romkin © (14.11.07 17:17) [100]
>
>
> > Ошибка не должна вылезти за метод обработки, но должна
> быть
> > сохранена для изучения и устранения.
>
> Мама, роди меня обратно...
А что вам не нравится или показ Exception для пользователя это ему чем-то поможет?
← →
Romkin © (2007-11-14 17:29) [109]
> А что вам не нравится или показ Exception для пользователя
> это ему чем-то поможет?
Обычно помогает. А то получается: нажал пользователь на кнопочку, а выполнилось или нет - у Пушкина спрашивать надо :)
Программа-то молчит как партизан!
Плюс исключение тем и хорошо, что всплывает по стеку вызовов, это его главное назначение. И отказываться от этой возможности по меньшей мере значит жить в каменном веке программирования.
← →
Reindeer Moss Eater © (2007-11-14 17:30) [110]А что вам не нравится или показ Exception для пользователя это ему чем-то поможет?
так вот оказывается кто придумал конструкцию типа:
try
...
except
ShowMessage("Ошибка какая-то, фик знает какая");
end;
← →
pasha_golub © (2007-11-14 17:31) [111]
> Romkin © (14.11.07 17:29) [109]
> Плюс исключение тем и хорошо, что всплывает по стеку вызовов,
> это его главное назначение.
Вот-вот, и без этой его особенности оно и нафиг никому не нужно.
> Черный Шаман (14.11.07 17:25) [108]
> А что вам не нравится или показ Exception для пользователя
> это ему чем-то поможет?
А пользователю можно показать красивую мордашку, мол не волнуйтесь, уважаемый. У нас тут внутре неонка барахлит, так шо мы тут лог запишем, туда положим, а вы будьте добры по этому адресу его отправьте. И будет юзер довольный аки слон. Надеюсь :)
← →
Romkin © (2007-11-14 17:34) [112]
> А пользователю можно показать красивую мордашку, мол не
> волнуйтесь, уважаемый. У нас тут внутре неонка барахлит,
> так шо мы тут лог запишем, туда положим, а вы будьте добры
> по этому адресу его отправьте. И будет юзер довольный аки
> слон. Надеюсь :)
А если на Application.OnException пустой обработчик присобачить - то вообще все всеглда работать будет!
← →
pasha_golub © (2007-11-14 17:35) [113]
> Reindeer Moss Eater © (14.11.07 17:30) [110]
> так вот оказывается кто придумал конструкцию типа:
Это цветочки. Как вам такое:
Obj := TSomeClass.Create;
try
try
{чего-то там...}
except
end;
finally
Obj.Free;
end;
Шобы, как говориться, "наверняка". И комар носа не подточит
← →
Черный Шаман (2007-11-14 17:36) [114]
> Romkin © (14.11.07 17:29) [109]
>
>
> > А что вам не нравится или показ Exception для пользователя
> > это ему чем-то поможет?
>
> Обычно помогает. А то получается: нажал пользователь на
> кнопочку, а выполнилось или нет - у Пушкина спрашивать надо
> :)
Вот вы дошли к тому что и я.
Я из всех нетривиальных методов(где стоит перехват исключений) возвращаю булевый код успеха. А по какой причине операция не выполнилась пользователя очень редко интересует, его интересует общий результат(Да/Нет).
А лог ошибки поможет уже мне понять что у него на самом деле произошло.
Мой вариант учитывает психологию. А так как продукт работает на десятках тысяч компьютеров мира, то всегода пользователя можно попросить выслать error.log в случае проблемы.
← →
DiamondShark © (2007-11-14 17:39) [115]
> Канадец (14.11.07 17:18) [102]
>
> > Единственный случай -- экземпляры на стеке в Ц++.
>
> Это не совсем верно. Нормальные программисты в таких случаях
> используют auto_ptr и shared_ptr
Во-первых, это библиотечные штучки, а речь идёт о языке.
Во-вторых, а что такое auto_ptr и shared_ptr? Экземпляры на стеке, в которые завёрнуты ссылки.
Те же яйца, вид сбоку.
← →
Romkin © (2007-11-14 17:41) [116]
> Вот вы дошли к тому что и я. Я из всех нетривиальных методов(где
> стоит перехват исключений) возвращаю булевый код успеха.
>
Я дошел?! Да эта технология использовалась еще... хм, думаю, не ошибусь, лет тридцать назад. Вот об этом я и говорю, каменный век. Человеку дали великолепный механизм обработки исключений - и он от него отказался...
← →
Reindeer Moss Eater © (2007-11-14 17:42) [117]А если на Application.OnException пустой обработчик присобачить - то вообще все всеглда работать будет!
Только не всегда это надо.
Пример.
Модульное приложение, в котором мой модуль (bpl).
К основому приложению прикрутили либу MadException. Все замечательно, ловит все несловленное внизу и шлет письма.
А я по привычке при вызове метода предварительно проверяю права текущего юзера:
if not HasRights then raise Exception.Create("Сори, дорогой, нету у тебя прав на эту функцию");
<остальной код>
← →
DiamondShark © (2007-11-14 17:42) [118]
> pasha_golub © (14.11.07 17:05) [94]
>
> А зачем? Это что за станция такая? Почему я не могу возбуждать
> произвольное исключение?
И что исполняющей среде с твоим произвольным исключением делать?
← →
DiamondShark © (2007-11-14 17:44) [119]
> Хм. в дельфе я всегда знаю, в какой момент будет удален
> объект.
> а в яве?
а зачем это знать?
← →
Reindeer Moss Eater © (2007-11-14 17:46) [120]Человеку дали великолепный механизм обработки исключений - и он от него отказался...
Ага. Исключения стали воспринимать как ошибки от которых надо избавляться.
← →
Romkin © (2007-11-14 17:46) [121]
> из всех нетривиальных методов(где стоит перехват исключений)
> возвращаю булевый код успеха. А по какой причине операция
> не выполнилась пользователя очень редко интересует, его
> интересует общий результат(Да/Нет). А лог ошибки поможет
> уже мне понять что у него на самом деле произошло.
Слушай, ты с Аксаптой, случайно, не работаешь? А то у меня друг ее администрит. И типовая ситуация - звонок "У нас терминал никак весы не найдет!" Шлют логи. Он перезванивает: "Сволочи, включите весы!!!"
Сейчас он их просто пингует, благо сетевые.
← →
Канадец (2007-11-14 17:47) [122]
> DiamondShark © (14.11.07 17:42) [118]
> Во-первых, это библиотечные штучки, а речь идёт о языке.
STL это неотъемлемая часть языка С++.
> Те же яйца, вид сбоку.
Поэтому я и написал "Это не совсем верно"
← →
Черный Шаман (2007-11-14 17:47) [123]
> pasha_golub © (14.11.07 17:31) [111]
> А пользователю можно показать красивую мордашку, мол не
> волнуйтесь, уважаемый. У нас тут внутре неонка барахлит,
> так шо мы тут лог запишем, туда положим, а вы будьте добры
> по этому адресу его отправьте. И будет юзер довольный аки
> слон. Надеюсь :)
А создатели FF про это и не знали, поэтому они все некритические ошибки выводят во внутреннюю консоль, а не на экран.
← →
mephasm (2007-11-14 17:48) [124]DiamondShark © (14.11.07 17:39) [115]
>Во-вторых, а что такое auto_ptr и shared_ptr? Экземпляры на стеке, в которые завёрнуты ссылки.
Вы забыли о вызове деструкторов полей объекта.
← →
Игорь Шевченко © (2007-11-14 17:48) [125]Romkin © (14.11.07 17:29) [109]
Исключение плохо тем, что его обработка нарушает простой и естественный ход программы. Также, как goto.
К тому же (это уже личное, наболевшее), с логикой, построенной на исключениях совершенно невозможно отлаживаться в среде, потому что нажатие кнопки F8 автоматически перемещает в то место, где возникло такое вот "логическое" исключение. И задавить его в среде тоже нельзя, потому что чать исключений такой класса нужно действительно обрабатывать, как исключения.
← →
Piter © (2007-11-14 17:50) [126]@!!ex © (14.11.07 17:19) [103]
Хм. в дельфе я всегда знаю, в какой момент будет удален объект
серьезно что ли? И в какой же момент?
Я то думал, что объект будет удален исключительно тогда, когда будет вызван деструктор объекта. Не раньше и не позже.
Точно также ресурсы можно освободить по вызову метода.
← →
Reindeer Moss Eater © (2007-11-14 17:52) [127]Исключение плохо тем, что его обработка нарушает простой и естественный ход программы. Также, как goto.
Ну if и case тоже нарушают простой ход программы.
Кроме того, исключение это совсем не goto куда-то там, а гоуту во вполне определенное место.
← →
Игорь Шевченко © (2007-11-14 17:54) [128]
> Ну if и case тоже нарушают простой ход программы.
if и case как раз не нарушают.
← →
Reindeer Moss Eater © (2007-11-14 17:58) [129]возбужденные исключения тоже не нарушают.
возвращаемся по стеку к месту вызова и все.
это не гоуту, это ранний возврат
← →
homm © (2007-11-14 17:59) [130]> [127] Reindeer Moss Eater © (14.11.07 17:52)
> Кроме того, исключение это совсем не goto куда-то там, а
> гоуту во вполне определенное место.
А у Вас гото всегда ведет кудато - там?
← →
Reindeer Moss Eater © (2007-11-14 18:02) [131]у меня вообще нет goto
← →
J_f_S (2007-11-14 18:03) [132]
> А у Вас гото всегда ведет кудато - там?
Гото может вести куда-то туда. Исключения всегда корректно раскручивают стек.
← →
Palladin © (2007-11-14 18:03) [133]
> Reindeer Moss Eater © (14.11.07 17:52) [127]
стоп стоп... if и case не могут вывести процесс исполнения на шаг, алгоритмически стоящий, выше текущего... именно это и является "нарушением простого и естественного хода программы"... потому то дополнительные конструкции continue и break не являются "злом"...
← →
Reindeer Moss Eater © (2007-11-14 18:05) [134]if condition then exit;
if condition then abort;
if condition then raise;
одно и то же.
но в последнем случае еще и некий workaround выполняется в виде показа мессаджа.
← →
Черный Шаман (2007-11-14 18:05) [135]
> Romkin © (14.11.07 17:46) [121]
>
>
> > из всех нетривиальных методов(где стоит перехват исключений)
> > возвращаю булевый код успеха. А по какой причине операция
> > не выполнилась пользователя очень редко интересует, его
> > интересует общий результат(Да/Нет). А лог ошибки поможет
> > уже мне понять что у него на самом деле произошло.
>
> Слушай, ты с Аксаптой, случайно, не работаешь? А то у меня
> друг ее администрит. И типовая ситуация - звонок "У нас
> терминал никак весы не найдет!" Шлют логи. Он перезванивает:
> "Сволочи, включите весы!!!"
> Сейчас он их просто пингует, благо сетевые.
>
А как бы пользователю помог бы показ этих ошибок, которые совсем не мешают работе программы? Код старый, не мною писаный, который проще завернуть чем переделывать. Да и времени нет, аналог Aero нужно делать для полустеклянного интерфейса.
21.10.2007 20:27:27:984||TVMListView.SetItem List index out of bounds (0)
21.10.2007 20:27:27:984||TLoadIconsThreadObject.UpdateIcon List index out of bounds (0)
22.10.2007 02:46:11:046||TFileListView.StartMonitorChanges Length(PathList.PIDLs)<=0 TFileListView.StartMonitorChanges
22.10.2007 02:46:11:062||TVMListView.SetItem Access violation at address 0041CBB9 in module "VistaStartMenu.exe". Read of address 00000008
22.10.2007 02:46:11:062||TFileListView.BuildItemsList Access violation at address 0041CBB9 in module "VistaStartMenu.exe". Read of address 00000008
22.10.2007 02:46:11:062||TVMListView.GetItem Access violation at address 0041CBB9 in module "VistaStartMenu.exe". Read of address 00000008
22.10.2007 02:46:11:062||TVMListView.PlaceItems Access violation at address 0041CBB9 in module "VistaStartMenu.exe". Read of address 00000008
22.10.2007 02:46:11:062||TPupupListView.ContinunePopup Access violation at address 00000000. Read of address 00000000
22.10.2007 02:46:11:062||TVMListView.GetItem Access violation at address 0041CBB9 in module "VistaStartMenu.exe". Read of address 00000008
22.10.2007 02:46:11:062||TLoadIconsThreadObject.UpdateIconsForListView Access violation at address 0041CBB9 in module "VistaStartMenu.exe". Read of address 00000008
← →
Reindeer Moss Eater © (2007-11-14 18:08) [136]Черный Шаман
так кроме шоумессаджа в блоке обработки можно и более полезный код писать.
← →
DiamondShark © (2007-11-14 18:09) [137]
> mephasm (14.11.07 17:48) [124]
> Вы забыли о вызове деструкторов полей объекта.
Точно, спасибо.
Но в данном случае непринципиально. Аналогов нет ни в Дельфи, ни, тем более, в жабе.
> Piter © (14.11.07 17:50) [126]
> Точно также ресурсы можно освободить по вызову метода.
Не, смотри. Пусть у нас есть контейнер, умеющий работать с каким-то абстрактным классом (вроде дельфийского TObjectList). Контейнер нифига не знает о том, используют ли содержащиеся в нём классы какие-либо ресурсы. Теперь мы напихаем в этот контейнер смесь экземпляров использующих и неиспользующих ресурсы, и отнимем возможность вызвать виртуальный деструктор.
Вот эта ситуация Зотова и пугает.
Зачем Зотову понадобилось пихать в обобщённый контейнер такую смесь -- он ни за что не признается. С разработчика контейнера взятки гладки. А вот пользователь контейнера прекрасно осведомлён о свойствах контейнера и тех объектов, которые он собственноручно туда положил, но "продолжал грызть кактус".
А виноват, конечно, язык.
← →
Черный Шаман (2007-11-14 18:09) [138]
> Reindeer Moss Eater © (14.11.07 18:08) [136]
>
> Черный Шаман
>
> так кроме шоумессаджа в блоке обработки можно и более полезный
> код писать.
Он там есть, но зачем он пользователю?
← →
NX (2007-11-14 18:12) [139]Всякий раз, когда говорю о том что программирую на Делфи, то почему-то у всех сразу становятся кислые рожи, как будто это язык лунатиков, почему?
← →
Reindeer Moss Eater © (2007-11-14 18:15) [140]Он там есть, но зачем он пользователю?
Нормальный и полезный блок обработки выглядит чуть менее примитивно.
А именно:
on E : Что-то там do молча иисправляем что-то там
on E : Что-то там еще do молча иисправляем что-то там еще
...
в остальных случаях показываем сообщение
← →
J_f_S (2007-11-14 18:16) [141]
> Черный Шаман (14.11.07 18:09) [138]
> > Reindeer Moss Eater © (14.11.07 18:08) [136]
> >
> > Черный Шаман
> > так кроме шоумессаджа в блоке обработки можно и более
> полезный
> > код писать.
> Он там есть, но зачем он пользователю?
Действительно, зачем пользователю стабильные отказоустойчивые приложения?
← →
Reindeer Moss Eater © (2007-11-14 18:18) [142]Действительно, зачем пользователю стабильные отказоустойчивые приложения?
Отказоустойчивость - это подавленные диагностические сообщения???
Превед!
← →
Игорь Шевченко © (2007-11-14 18:20) [143]NX (14.11.07 18:12) [139]
Смени круг общения.
Reindeer Moss Eater © (14.11.07 17:58) [129]
> возбужденные исключения тоже не нарушают.
> возвращаемся по стеку к месту вызова и все.
> это не гоуту, это ранний возврат
Дабы пояснить иллюстрацией:
Имеет код:
try
try
if SomeBadCondition then
raise Exception1.Create (...)
.....
if SomeAnotherBadCondition then
raise Exception2.Create (...)
except
on E: Exception1 do
begin
.....
end;
on E: Exception2 do
begin
.....
raise Exception.Create (...+E.Message);
end;
on E: Exception do
begin
.....
end;
end;
.....
except
on E: Exception do
begin
.......
end;
end;
Писать лень, но этот кусок может быть обернут еще в несколько try...except, try..finally
Если кто-то скажет, что ход исполнения программы можно легко и просто проследить, значит мне пора на свалку истории.
← →
J_f_S (2007-11-14 18:22) [144]
> Отказоустойчивость - это подавленные диагностические сообщения?
> ??
Я не про подавленные мессаджи, а про код обработки ошибок, конечно.
← →
Reindeer Moss Eater © (2007-11-14 18:22) [145]Если кто-то скажет, что ход исполнения программы можно легко и просто проследить, значит мне пора на свалку истории.
Вообще да согласен, но это из серии "Корявый код можно нарисовать на любом языке"
← →
Azize © (2007-11-14 18:24) [146]По сабжу
Исходя из логики препода
java=C=C++=MSV C++=MSV=MSV Basic = Basic = Фуфло pascal и то лучше
)))
← →
Игорь Шевченко © (2007-11-14 18:25) [147]Reindeer Moss Eater © (14.11.07 18:22) [145]
> Вообще да согласен, но это из серии "Корявый код можно нарисовать
> на любом языке"
А идеи по выпрямлению есть ? :)
← →
Reindeer Moss Eater © (2007-11-14 18:30) [148]try
if SomeBadCondition then
raise Exception1.Create (...)
Вообще это клиника конечно. Обычно один программер возбуждает исключения для другого программера и т.д.
То есть автор компонента/библиотеки - пользователю библиотеки.
Но что бы самому себе?
← →
Reindeer Moss Eater © (2007-11-14 18:31) [149]Именно в таком виде
← →
Azize © (2007-11-14 18:32) [150]
> java=C=C++=MSV C++=MSV=MSV Basic = Basic = Фуфло pascal
> и то лучше
вернее
java=C=C++=MSV C++=MSVS=MSV Basic = Basic = Фуфло pascal
← →
@!!ex © (2007-11-14 18:47) [151]> а зачем это знать?
А когда освобождать ресурсы?
> серьезно что ли? И в какой же момент?
В момент вызова дескуртора.
> Я то думал, что объект будет удален исключительно тогда,
> когда будет вызван деструктор объекта. Не раньше и не позже.
>
> Точно также ресурсы можно освободить по вызову метода.
По вызову какого метода????
Какой метод ява вызывает при удалении объекта????
← →
Плохиш © (2007-11-14 18:47) [152]
> Reindeer Moss Eater © (14.11.07 18:05) [134]
> if condition then exit;
>
> if condition then abort;
>
> одно и то же.
да шо ви говорите?
← →
Piter © (2007-11-14 18:51) [153]@!!ex © (14.11.07 18:47) [151]
Какой метод ява вызывает при удалении объекта????
а какой метод Delphi вызывает при удалении объекта?
← →
@!!ex © (2007-11-14 18:53) [154]> [153] Piter © (14.11.07 18:51)
А его вызываю я, когда МНЕ это нужно.
На дельфи:
есть ресурсы, которые мне надо освободить при релизе объекта.
Я тупо освобождаю ресурсы в деструкторе.
на яве:
есть ресурсы, которые мне надо освободить при релизе объекта.
где я должен их освобождать? ОТдельный метод? Так вызов этого метода никак не связан с релизом объекта.
← →
Virgo_Style © (2007-11-14 18:55) [155]Насколько я себе уяснил, зло прежде всего в том, что освобождать объект на Delphi - это нерушимое правило, и делается это заранее условленными методами.
Для Java же предполагается, что все случится автоматически, а лично я, признаться, справку читаю только тогда, когда мне что-то становится неясно, и боюсь, что не я один... а ресурсы-то потекут, поскольку о том, что надо вызывать еще что-то, я попросту не буду знать.
Конечно, я в этом случае буду сам себе злобный буратино, но для чего лишать разработчика возможности снизить чужую буратинистость?
← →
Черный Шаман (2007-11-14 18:59) [156]
> Reindeer Moss Eater © (14.11.07 18:05) [134]
>
> if condition then exit;
>
> if condition then abort;
>
> if condition then raise;
>
> одно и то же.
>
> но в последнем случае еще и некий workaround выполняется
> в виде показа мессаджа.
Exception можно использовать только для выхода из нескольких вложенных вызовов методов, а если нужен выход из одного текущего вызова метода, то намного удобнее Exit и вернуть логический статус выполнения операции.
← →
pasha_golub © (2007-11-14 19:00) [157]
> Reindeer Moss Eater © (14.11.07 18:30) [148]
>
> try
> if SomeBadCondition then
> raise Exception1.Create (...)
>
> Вообще это клиника конечно. Обычно один программер возбуждает
> исключения для другого программера и т.д.
>
Поддерживаю оратора. Но самому себе тоже можно. В другой, например, функции, которая будет вызвана.
2ИШ
То что отлаживать с excption"ами иногда муторно, я согласен. Но зато, получили Exception, тут же выкинуло нас в код, жмакаем Ctrl+Alt+S и имеем стек откуда шо пришло. А в ином случае, пришлось бы по F7 спускаться самим.
← →
DiamondShark © (2007-11-14 19:01) [158]
> @!!ex © (14.11.07 18:47) [151]
> > а зачем это знать?
>
> А когда освобождать ресурсы?
Удаление объекта и освобождение ресурсов -- это разные операции.
> По вызову какого метода????
> Какой метод ява вызывает при удалении объекта????
При удалении объекта ява вызывает метод finalize(). Но это не важно. Она могла бы не вызывать вообще никакого метода. Это нисколько не мешает освобождать ресурсы.
← →
@!!ex © (2007-11-14 19:01) [159]Эксцепшены очень клевая штука на стадии разработки проекта.
← →
@!!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, если не обосновано.
← →
DiamondShark © (2007-11-14 22:00) [189]
> Юрий Зотов © (14.11.07 20:48) [178]
>
> Вообще-то, в этом примере описана постановка задачи. Встречный
> вопрос - Вы действительно считаете, что постановка задачи
> должна быть привязана к какому-либо языку? Это не так. LOL.
В данном случае -- привязана. Потому что зоопарк классов у вас уже существует. И задача -- это наведение костылей к уже имеющимся классам.
> > он либо будет освобождать ресурсы до возврата из метода
> execute,
> И тогда потеряет возможность их кэширования. Потому что
> при следующем вызове метода execute ему придется захватвать
> их по новой. LOL.
Нет ножек -- нет конфеток.
Я ещё раз повторяю: Ява-разработчик о таких моментах помнит, и такой интерфейс никогда не изобразит. Разве что это его вторая, после хеловорлда, работа на Яве.
> А я, разработчик движка, непонятно каким волшебным образом
> узнаю об этом новом интерфейсе через три года после запуска
> программы в эксплуатацию. И немедленно доработаю движок
> под юзание этого свалившегося с Луны интерфейса. И все юзеры
> (а их будут тысячи, по всей стране) немедленно переинсталлируют
> программу. LOL.
Юродствуете? Ню-ню.
Если вы привыкли задачи решать через анус, медицина бессильна.
> Хотя выше я уже сказал и
> о том, что программа пишется на Джаве, и о том, что интерфейс
> есть.
Не сказал.
> Параметры и доступ к окружению у объекта есть. Я же не буду
> приводить здесь всю постановку задачи, там одних диаграмм
> хрен знает сколько. Вообще-то, могли бы и догадаться.
Не надо брать на понт. В задаче "хост с плагинами" диаграм хрен-да-нихрена.
Всё дело в том, что хост-плагинное взаимодействие в своё время разрабатывалось левой ногой за пять минут под пивко. Если бы тогда подумалось шесть минут на трезвую голову, то сейчас проблем бы не было.
> Код - в студию.
А я нанимался?
← →
Romkin © (2007-11-14 22:02) [190]При удалении объекта ява вызывает метод finalize().
Угу. Выше были приведены условия вызова этого метода. Лучше не нать!
← →
Юрий Зотов © (2007-11-14 22:03) [191]С некоторыми персонажами все ясно. Могут заниматься блудословием и дальше, сколько им угодно. Адью.
← →
Romkin © (2007-11-14 22:03) [192]
> Эксцепшены очень клевая штука на стадии разработки проекта.
Угу. Только, плиз, опусти вторую половину фразы, и все будет нормально. ТАк задумано.
← →
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]
>С некоторыми персонажами все ясно. Могут заниматься блудословием и дальше, сколько им угодно. Адью.
Нет, вот так конечно
Это вы исключение выбросили? :)))
← →
Юрий Зотов © (2007-11-14 22:07) [195]> Mambasa (14.11.07 22:04) [193]
Угу. Не было другой возможности прервать бесконечный цикл. В русском народном сленге он еще называется - что-то там про Фому и Ерему.
← →
Romkin © (2007-11-14 22:12) [196]
> А если жмакать код как в голову придет, то екзепшены не
> помогут.
Тут ничего не поможет, увы
← →
Черный Шаман (2007-11-14 22:13) [197]
> Romkin © (14.11.07 21:50) [187]
>
> Черный Шаман (14.11.07 18:05) [135] Просматриваю список.
> ..
> Ошибка программиста...
> Ошибка программиста...
> AV - это задница...
> ...
> Мля! %:?*!
> Прошу прощения, в моих привычках не числится сокрытие собственных
> огрехов. Я так воспитан. Все.
Я не говорю что эти ошибки не нужно исправлять(хотя они возникают раз в 2-3 дня, отловить сложно). Я о том, что пользователю стандартное сообщение об AV ничем бы не помогло, он бы даже адреса памяти не запомнил чтобы в службу техподдержки сообщить.
← →
Romkin © (2007-11-14 22:28) [198]
> Я о том, что пользователю стандартное сообщение об AV ничем
> бы не помогло, он бы даже адреса памяти не запомнил чтобы
> в службу техподдержки сообщить.
А мой опыт говорит, что помогло бы. Хотя бы потому, что если (реально, млин!) нам звонит юзверь, и по слогам читает асес-виолейшен, то весь отдел ставится на уши до решения трамблемы. По факту.
Кстати, сугубо рекомендую: глядишь, и скрывать ничего не нать будет.
PS. Лог ведется, но сугубо параллельно, на случай, если упустили.
← →
Romkin © (2007-11-14 22:32) [199]Ну, честно признаться, сначала таки ждут повтора. Но если повторилось - не далее как месяц назад семь человек пытались воспроизвести два дня. Весь свой рабочий день, нач отдела тоже участвовал. Вроде бы устранили.
← →
Плохиш © (2007-11-14 22:39) [200]
> Piter © (14.11.07 19:27) [169]
> @!!ex © (14.11.07 18:53) [154]
> А его вызываю я, когда МНЕ это нужно
>
> а что тебе мешает вызывать некий метод объекта, который
> будет делать тоже самое, что Destroy в Delphi? Можешь даже
> назвать его также.
Странно, за столько лет ни разу не приходилось вызывать деструктор явно. Может я чё не так делаю?
← →
Черный Шаман (2007-11-14 23:30) [201]
> Romkin © (14.11.07 22:28) [198]
>
>
> > Я о том, что пользователю стандартное сообщение об AV
> ничем
> > бы не помогло, он бы даже адреса памяти не запомнил чтобы
> > в службу техподдержки сообщить.
>
> А мой опыт говорит, что помогло бы. Хотя бы потому, что
> если (реально, млин!) нам звонит юзверь, и по слогам читает
> асес-виолейшен, то весь отдел ставится на уши до решения
> трамблемы. По факту.
> Кстати, сугубо рекомендую: глядишь, и скрывать ничего не
> нать будет.
> PS. Лог ведется, но сугубо параллельно, на случай, если
> упустили.
Во у вас в отделе 7 человек, а у нас два из которых только программированием и проектированием занимается 1 - Я (второй мой начальник занимается в основном маркетингом). А тот код достался в наследство, пока нет времени и ресурсов его переделать.
Баги есть довольно конкретные про которые давно известно, но по юзабилити программа уже опережает решения от такого гиганта как Microsoft.
← →
Piter © (2007-11-14 23:53) [202]Плохиш © (14.11.07 22:39) [200]
Странно, за столько лет ни разу не приходилось вызывать деструктор явно. Может я чё не так делаю?
ах ах... Да какая разница Destroy, Free или там FreeAndNil, все они по сути вызывают деструктор - это их главная задача, просто вешаются проверки, доп. функционал и все такое.
Ты просто обязан в дельфи вызывать уничтожение объекта явно, потому что как раз в отличии от java не поддерживается сборка муссора для классов.
А может ты действительно чё не так делаешь ;)
← →
Piter © (2007-11-14 23:53) [203]Черный Шаман (14.11.07 23:30) [201]
но по юзабилити программа уже опережает решения от такого гиганта как Microsoft
ну это стандартное дело, разработчику всегда кажется, что его программа наиболее удобная. А даже если че не так - это у пользователей руки кривые и ошибка в ДНК ;)
← →
Плохиш © (2007-11-14 23:58) [204]
> Piter © (14.11.07 23:53) [202]
А вот TObjectList как-то без моего участия вызывает деструктор. Да и владелец то же, для тех кем владеет... Или ты об чём?
← →
Черный Шаман (2007-11-15 00:09) [205]
> Piter © (14.11.07 23:53) [203]
>
> Черный Шаман (14.11.07 23:30) [201]
> но по юзабилити программа уже опережает решения от такого
> гиганта как Microsoft
>
> ну это стандартное дело, разработчику всегда кажется, что
> его программа наиболее удобная. А даже если че не так -
> это у пользователей руки кривые и ошибка в ДНК ;)
Нет на любые проблемы у наших пользователей мы реагируем очень быстро. Вот пришлось динамический балансировщик загрузки процессора потоками сканирования списка файлов написать, чтобы сканирование занимало процессор только когда он полностью свободен.
А то даже на нити с Priority = idle пользователи жаловались.
А на вот те баги с AV они даже не подозревают.
← →
iZEN © (2007-11-15 00:20) [206]К теме: delphi = pascal = языки для начинающих?
По-моему, для начинающих язык Ruby самое то.
(Кстати, в NetBeans 6.0, которая выйдет в декабре, будет (=уже есть в бете) поддержка программирования на Ruby.)
← →
Piter © (2007-11-15 00:39) [207]Плохиш © (14.11.07 23:58) [204]
А вот TObjectList как-то без моего участия вызывает деструктор
ты и на Java можешь написать контейнер, который будет вызывать некий метод самостоятельно при удалении из списка item"а, который приведет к уничтожению объекта. И что дальше?
← →
Плохиш © (2007-11-15 00:43) [208]
> Piter © (15.11.07 00:39) [207]
goto [74]
← →
Юрий Зотов © (2007-11-15 00:45) [209]> Piter © (15.11.07 00:39) [207]
А если контейнер написан раньше, чем item и контейнеру этот метод item"а, соответственно, неизвестен, то как?
← →
Piter © (2007-11-15 01:07) [210]Юрий Зотов © (15.11.07 0:45) [209]
А если контейнер написан раньше, чем item и контейнеру этот метод item"а, соответственно, неизвестен, то как?
а на этот вопрос вам уже отвечали - у java другая логика программирования. Если эта логика не нравится лично вам - это одно, но утверждения, что язык плох - это другое. Говорить, что lisp плохой язык потому, что на нем неудобно писать 3D-приложения бессмысленно.
В java логике по идее нет месту нетипизированным указателям, поэтому там и не предусмотрено способов и мест по уничтожения таких "нестандартных" ресурсов, такие ресурсы неприемлимы в java. В этом подходе как и в любом другом есть плюсы, а есть минусы.
← →
Черный Шаман (2007-11-15 01:22) [211]
> Юрий Зотов © (15.11.07 00:45) [209]
>
> > Piter © (15.11.07 00:39) [207]
>
> А если контейнер написан раньше, чем item и контейнеру этот
> метод item"а, соответственно, неизвестен, то как?
Определить предка с "виртуальным java-декструктором" для всех итемов. От него и наследовать все итемы.
Delphi тоже не сам писался.
← →
Канадец (2007-11-15 01:23) [212]
> Юрий Зотов © (15.11.07 00:45) [209]
IMHO ваша проблема в [166] совсем не проблема языка, а проблема "специалистов" разработавших эту систему. "Проблема не в сортирах, а в головах", как говаривал небезызвестный персонаж.
Есть набор совершенно произвольных классов, о каждом из которых известно лишь то, что он имеет метод execute. Задача стоит так, что писаны эти классы могут быть кем угодно, как угодно и когда угодно, документации на них нет, исходников тоже нет.
и
По окончании цикла - убить все экземпляры в кэше и освободить все захваченные ими ресурсы. Причем неизвестно, какие именно.
Отсюда я делаю вывод, что есть некие объекты, которые могут захватывать некие ресурсы (поправьте меня если я не прав). Ну если они их захватывают, то они ж и должны их освобождать! Где они это делают? Точнее разработчики, которые разрабатывали эту систему, где предусматривали освобождение ресурсов? Неужели в finalize? Для этих целей и существует IDisposable и вот тот интерфейс, который предоставил этим объектам метод Execute должен был и предоставить IDisposable.
Ну а сейчас уже конечно поздно пить боржоми. В рамках описанного сценария проблему, скорее всего, не решить.
← →
Юрий Зотов © (2007-11-15 01:24) [213]> Piter © (15.11.07 01:07) [210]
> В java логике по идее нет месту нетипизированным указателям, поэтому
> там и не предусмотрено способов и мест по уничтожения
> таких "нестандартных" ресурсов, такие ресурсы неприемлимы в java.
Миш, ты бы не спорил о том, что не вполне понимаешь, а? Захваченные ресурсы - это далеко не только память. Это открытые файлы, коннекты к БД и многое другое. И все это в джаве есть, потому что без этого никуда. И никакие указатели тут вообще ни при чем.
И метод, где захваченные объектом ресурсы можно освободить, в джаве тоже есть. По крайней мере, декларирован - причем именно на уровне языка. Но не работает. Похоже, со дня своего рождения. И это есть глюк, причем тоже глюк языка. Вопиющий. И без всяких плюсов.
← →
Юрий Зотов © (2007-11-15 01:32) [214]> Черный Шаман (15.11.07 01:22) [211]
> Определить предка с "виртуальным java-декструктором" для всех итемов.
> От него и наследовать все итемы.
Зачем определять то, что уже и так есть? Это Object с его finalize. Который ОБЯЗАН работать.
> Канадец (15.11.07 01:23) [212]
Проблемы нет, потому что ввести в интерфейс новый метод еще не поздно (и об этом говорилось). Но на фига делать искусственные подпорки, ежели (повторюсь) существует finalize и он ОБЯЗАН работать?
Тем не менее, подпорки эти приходится делать. И только из-за глюкавости.
← →
Черный Шаман (2007-11-15 01:50) [215]
> Юрий Зотов © (15.11.07 01:32) [214]
>
> > Черный Шаман (15.11.07 01:22) [211]
>
> > Определить предка с "виртуальным java-декструктором" для
> всех итемов.
> > От него и наследовать все итемы.
>
> Зачем определять то, что уже и так есть? Это Object с его
> finalize. Который ОБЯЗАН работать.
Он и работает. Просто стандартом не определено когда он должен вызыватся. А вызывается он только когда сборщик мусора решит очистить память. А решит он это когда погода будет хорошей и положение звёзд правильным или же приложение выжрет ВСЮ память.
Так что все правильно, он вызывается, но недерминированно по времени, что николько не противоречит официальной документации.
Хотите детерминированно - реализуйте свой метод.
Вот вы других обвиняете в ламеризме, а у самих "компилятор виноват".
← →
Канадец (2007-11-15 01:56) [216]
> Юрий Зотов © (15.11.07 01:32) [214]
> существует finalize и он ОБЯЗАН работать?
Работать в смысле освобождать ресурсы или в смысле вызываться вообще? С первым не согласен, со вторым согласен.
Кстати далеко не факт, что пример в [80] это глюк. Консоль может закрывться раньше, чем finalize у объектов вызываться. Попробуйте в файл что-нибудь записать.
← →
Piter © (2007-11-15 02:02) [217]Юрий Зотов © (15.11.07 1:24) [213]
Миш, ты бы не спорил о том, что не вполне понимаешь, а?
а что я по вашему не вполне понимаю? Что такое указатели? Вы сами про них говорили, а теперь оказывается я не понимаю.
Юрий Зотов © (15.11.07 1:24) [213]
это далеко не только память. Это открытые файлы, коннекты к БД и многое другое
и это многое другое должно быть типизированными объектами, структурами или что-то в подобном духе. Которые будут корректно уничтожены сборщиком мусора java.
← →
Piter © (2007-11-15 02:04) [218]Канадец (15.11.07 1:56) [216]
Консоль может закрывться раньше, чем finalize у объектов вызываться. Попробуйте в файл что-нибудь записать
кстати
← →
Юрий Зотов © (2007-11-15 02:44) [219]> Черный Шаман (15.11.07 01:50) [215]
В [80] я привел код теста, который показывает, что finalize не вызвался ни разу за все время жизни приложения (хотя счетчик ссылок на объект обнулялся, как минимум, дважды). Как это понимать? Очевидно, так, что за все время жизни приложения GC ни разу не решил, что пора почистить память. По крайней мере, других объяснений нет.
Но возникает вопрос - а если бы объект открыл файл или коннект к БД, а код его освобождения был прописан именно в finalize (кстати, в полном соответствии с рекомендациями документации) то что, этот ресурс так и остался бы открытым? Чушь ведь.
> Канадец (15.11.07 01:56) [216]
> Работать в смысле освобождать ресурсы или в смысле
> вызываться вообще?
Вызываться, конечно. Остальное - что в нем написано, то и будет, хоть ресурсы освобождаем, хоть кошку на экране рисуем.
> Консоль может закрывться раньше, чем finalize у объектов вызываться.
Если в консоли второй раз появилась строка "created", значит, до этого она точно была открыта. Но строки "finalized" в ней не появилось - значит, метод finalize вызван не был, хотя счетчик ссылок на объект точно был обнулен. Но, возможно, он был вызван перед завершением программы, так решил GC? Хорошо, давайте проверим, как Вы и предложили. Вот измененный тест:public class DisposableObject {
private FileOutputStream stream;
public DisposableObject() {
super();
try {
stream = new FileOutputStream("C:/Test.txt");
writeString("created");
} catch (IOException e) {
e.printStackTrace();
}
}
public void writeString(String s) throws IOException {
stream.write((s + "\n").getBytes());
System.out.println(s);
}
protected void finalize() throws Throwable {
writeString("finalized");
stream.flush();
stream.close();
super.finalize();
}
}
И измененная запускалка теста:public static void main(String[] args) {
DisposableObject obj = new DisposableObject();
try {
obj.writeString("isWorking");
} catch (IOException e) {
e.printStackTrace();
}
obj = null;
}
А вот результат - и в консоли, и в файле одно и то же:created
isWorking
Никаких вызовов finalize, как видим, снова не зафиксировано. Что удручает.
← →
Юрий Зотов © (2007-11-15 02:48) [220]> Piter © (15.11.07 02:02) [217]
> а что я по вашему не вполне понимаю?
Что такое ресурсы.
> и это многое другое должно быть типизированными объектами,
> структурами или что-то в подобном духе. Которые будут корректно
> уничтожены сборщиком мусора java.
Миш, ты никак не мог лучше подтвердить мои слова о том, что ты не вполне понимаешь, что такое ресурсы. Какие объекты? Какие сборщики мусора будут тебе хэндлы закрывать? При чем тут вообще сборщик мусора?
← →
Romkin © (2007-11-15 07:55) [221]
> это далеко не только память. Это открытые файлы, коннекты
> к БД и многое другоеи это многое другое должно быть типизированными
> объектами, структурами или что-то в подобном духе. Которые
> будут корректно уничтожены сборщиком мусора java.
Да, конечно. Вполне логично, что создал я объект типа файл - файл открыт, пишу-читаю. Стал объект не нужен - он уничтожился, файл закрыт. Только маленькая проблема: а когда?
← →
Evgeny V © (2007-11-15 08:17) [222]
> Юрий Зотов © (15.11.07 02:48) [220]
> Какие сборщики мусора будут тебе хэндлы закрывать? При чем
> тут вообще сборщик мусора?
Для программирования в таких средах как .NET, JAVA,BlackBox и подобных надо просто менять несколько идеологию - как , когда и зачем.... Программу за программиста все равно никто не напишет. Поэтому кое-что надо делать самому, ручками и в нужное время. А вынос освобождения например файловых ресурсов (или каких других неуправляемых ресурсов) в финализатор - это просто неверный подход в данном случае. О чем указывают все учебники по JAVA, .NET и прочие... Правило относительно простое - если есть реализация IDisposable - то и надо воспользоваться соответствующим методом для освобождения ресурса. Впрочем я повторил [212] Что касается ссылок на описание, что делает finalize то надо помнить, что это просто последний бастион,для освобождения ресурсов, которые надо было явно осбодить, но не сделали этого. Никто не гарантирует, что метод будет вызван в определенный момент. А если сборщик мусора решит, что нет необходимости на данный момент уничтожать объект и освобождать память, то вообще вопрос будет ли вызван финализатор.
Почитайте - рекомедую. Кстати и книгу на которую там ссылаются, есть ее русское издание (Философия Ява).
http://iais.kemsu.ru/odocs/javax/finally.html
"Деструкторов нет. А что вместо?
Многие программисты (особенно только что пересевшие с C++), видят замену деструкторов в виде методов finalize. Это не есть правильно. Во первых, этот метод не вызовется, пока на объект имеются ссылки. Нет гарантии, что он вызовется тогда, когда вам это нужно. Он может вообще никогда не вызваться. Есть, конечно, метод System.runFinalizersOnExit(), но он уже давно deprecated из-за возможных deadlock-ов. Как справедливо заметил Bruce Eckel в замечательной книжке Thinking in Java метод finalize стоит использовать только для того, чтобы освободить память (или другой, не очень критичный ресурс), выделенную в native методах. Для прочих же ресурсов следует добавить явный вызов метода очистки ресурсов (он может называться по-разному - close, dispose, cleanup, и т.д.), внутри конструкции finally. Внутри finally - для того, чтобы не прозевать какое-нибудь исключение. Пример типичных конструкций:
"
Поэтому надо реализовать и/или использовать IDisposable, когда надо явно освободить ресурсы(как правило методы Close,Dispose)
Кстати - кроссплатформенность, даже в урезанном виде весьма неплохая вещь, когда приходится с этим сталкиваться....
← →
Evgeny V © (2007-11-15 08:20) [223]
> Romkin © (15.11.07 07:55) [221]
Когда сам его закроешь, или если забыл, то когда решит GC, а это только ему одному известно:-)))
← →
Romkin © (2007-11-15 08:23) [224]Вот давайте разберемся, тем более что в Юрий Зотов © (15.11.07 02:44) [219] есть код с потоком.
Вот что подразумевается, когда говорят, что о времени жизни объекта заботится не надо? Это значит, что если он не нужен - он уничтожается.
Замечательно! Возьмем stream. Фактически - мы создаем из строкового имени файла объект, представляющий его содержимое, так ведь?
И красиво было бы, если бы поток не надо было закрывать, зачем? Сам закроется, когда будет не нужен. Но обратите внимание: есть вызов close();
Зачем? Вы скажете: а я его хочу потом снова открыть и поработать. Ну и что? А почему нельзя создать новый объект потока? Почему не принять, что файл открывается при создании (а так и есть), и совершенно симметрично закрывается при уничтожении? В Delphi поток так и работает, кстати. Логично же?
Тогда при вызове метода close мы объявляем, что объект не нужен. Это - вызов логического деструктора. И если я вызываю close, то почему я не могу в этом же месте просто уничтожить объект?
Получается какая-то нелогичность: все советуют иметь метод, освобождающий ресурсы, но только не деструктор! Млин. С одной стороны - если я освободил внешние ресурсы, объект мне не нужен, с другой - избавиться я от него не могу, этим занимается сборщик мусора!
Спрашивается, а оно мне надо? Точнее, а нафига мне этот сборщик мусора? НУ насобачили нечно, заботящееся об освобождении памяти, и при этом еще мешающее мне освобождать остальные ресурсы?!
Не считайте меня идиотом: если я позаботился о закрытии потока, то об уничтожении собственно объекта я тоже позаботиться в состоянии. И мне бы подошло совмещение этих двух действий.
Почему в java я лишен возможности явно уничтожить объект, когда мне хочется?! Что за детский сад?
← →
Evgeny V © (2007-11-15 08:38) [225]
> Romkin © (15.11.07 08:23) [224]
GC никак не знает, что вам не нужен файл уже сейчас, что его надо закрыть, разрешить им позоваться другому. Он закроет файл, когда увидит, что поток уже не используется, нет ссылок на него. Но - это будет неизвестно когда, то есть недетерминированный процесс. Надо что бы файл был свободен сразу после того, как мне он не нужен. Для чего и вызывается его метод Closeю Почему нельзя создать новый объект потока? Можно, только я ведь мог открыть файл в эксклюзивном режиме. Close не уничтожает объект, он закрывает файл. Класс уничтожиться уже GC(или нет, такое возможно). Кстати на вопросы в этом посте и тебе поможет hfphttp://iais.kemsu.ru/odocs/javax/finally.html -статья хорошая. Не все яве было и есть возможно гладко. Но возможность явного освобождние ресурсов типа файл, битмап и т.п. вещб полезная. Ибо GC не вызывается явно, даже когда мы вызываем его сами GC.Collect() - это не гарантия, что он решит, что все объекты ненужные надо освободить. Кстати - идиотом я тебя и не думал считать:-))
> Почему в java я лишен возможности явно уничтожить объект,
> когда мне хочется?! Что за детский сад?
И в c# и в компонент паскаль и еще много где, где есть сборщик мусора. Кстати используя менеджер памяти дельфи, я тоже не всегда могу явно освободить блок памяти(вернуть его менеджеру не есть освободить) - ну что за детский сад:-))
← →
DiamondShark © (2007-11-15 08:58) [226]
> Почему в java я лишен возможности явно уничтожить объект,
> когда мне хочется?! Что за детский сад?
Опять сакрализация "уничтожения объекта".
Объект -- это просто область памяти. Какая разница, каким образом неиспользуемая область памяти попадёт под повторное использование?
Отвыкайте мыслить освобождение памяти и закрытие ресурсов как однозначно связанные операции -- и будет вам щасте.
← →
@!!ex © (2007-11-15 08:59) [227]> А решит он это когда погода будет хорошей и положение звёзд
> правильным или же приложение выжрет ВСЮ память.
...
> Вот вы других обвиняете в ламеризме, а у самих "компилятор
> виноват".
По вашему непредсказуемый компилятор не виноват?
ИМХО прогать под компилятор работа которого зависит от положения звезд.. это не очень хорошо...
← →
Evgeny V © (2007-11-15 09:12) [228]
> @!!ex © (15.11.07 08:59) [227]
Например на дельфи 6 со стандартным менеджером памяти - в цикле очень часто выделяем блоки памяти примерно одного размера:
Getmem и через какое-то время FreeMem. Скажи мне когда совпадут звезды так, что бы освобожденный FreeMem блок памяти был сразу же возвращен системе???
← →
Romkin © (2007-11-15 09:30) [229]
> Опять сакрализация "уничтожения объекта".Объект -- это просто
> область памяти. Какая разница, каким образом неиспользуемая
> область памяти попадёт под повторное использование?Отвыкайте
> мыслить освобождение памяти и закрытие ресурсов как однозначно
> связанные операции -- и будет вам щасте.
А зачем мне вообще об этом думать? Если меня добрая Виртуальная машина избавляет от дум о памяти - пусть освободит и от дум о ресурсах!
> Не все яве было и есть возможно гладко. Но возможность
> явного освобождние ресурсов типа файл, битмап и т.п. вещб
> полезная.
Вот об этом и речь. Java как-то остановилась на середине пути: что-то освобождается (не будем упоминать о том, что это что-то - только память), а что-то - нет.
Более того, если в Delphi есть четкое место освобождения всех ресурсов, деструктор, то в java - каждый предусматривает его для себя. Один назовет Close, другой - Dispose... А тот, кто пользует, должен знать, как это называется и как вызывать, более того: обязан это сделать.
Вот Delphi:function BigBrother.GetMeTheFile(const FileName: string): IStream;
var
Stream: TStream;
begin
Stream := TFileStream.Create(FileName, fmOpenRead);
Result := TStreamAdapter.Create(Stream, soOwned);
end;
//Пользуем, где-то:
procedure ReadFile;
var
Stream: IStream;
begin
Stream := BigBrother.GetMeTheFile("c:\a.txt");
Stream.Read(...);
//Big thanks!
end;
И все... Все уже давно договорено: где тут open, close, dispose?
Почему в Java так нельзя?
← →
Evgeny V © (2007-11-15 09:50) [230]
> Romkin © (15.11.07 09:30) [229]
> Вот об этом и речь. Java как-то остановилась на середине
> пути: что-то освобождается (не будем упоминать о том, что
> это что-то - только память), а что-то - нет.
Согласен, я не говорю, что лучше, а что хуже. Мне в последнее время все больше нравится GC, а не явное освобождение памяти. А насчет ресурсов типа файл - то как бы тыт решил эту проблему в виртуальной машине? Я думал о таком же, когда начла, но честно говоря не придумал.
Про
> И все... Все уже давно договорено: где тут open, close,
> dispose?
> Почему в Java так нельзя?
Ты используешь один вариант, но ведь есть и Assign в паскале. И в JAVA есть не один вариант и класс для открытия файла.
В JAVA тоже все договорено. Только под другую иделогоию. И не только в JAVA, а там где есть сборщики мусора. Скажем так, тебе нравится детерминированный подход. А мне в некоторых случаях стал нарвится подход с подскакзой,что-то делается за меня. Но о чем-то я все равно обязан помнить. Без этого пока никак. Но ведь и ты пользуешься подсказчиками в виде ObjectInspector и т.п и визульными редакторами и прочим. Удобно просто. Что-то можно в JAVA. что-то нельзя, так же и для других языков. Для меня GC -это просто помощник:-) Но есть вещи, которые еще делаю в дельфи и не жалею кстати, что в дельфи. Так же ка и не жалею, что делаю задачи на C# Выбор инструмента - это задача, ресурсы и скорость выполнения задачи, начальство и мои предпочтения:-)
Давай скажем так - дело не в JAVA для тебя, дело в сборщике мусора, он ебе не нравится. А это не один язык, а много разных. А сборщик мусора - ну это дело предпочтений отчасти.
← →
Игорь Шевченко © (2007-11-15 09:59) [231]pasha_golub © (14.11.07 19:00) [157]
> 2ИШ
> То что отлаживать с excption"ами иногда муторно, я согласен.
> Но зато, получили Exception, тут же выкинуло нас в код,
> жмакаем Ctrl+Alt+S и имеем стек откуда шо пришло. А в ином
> случае, пришлось бы по F7 спускаться самим.
Ты не до конца понял - в случае, который я привел, Exception возбуждается при вполне корректной ситуации, то есть, он служит чем-то вроде условного перехода. Только среда об этом не знает и каждый раз "нас выкинуло в код", который нам совершенно неинтересен.
Тебе бы понравилось, если бы ты вызывал какую-то подпрограмму, а внутри ее по if-у стояла бы точка останова и каждый раз среда бы там останавливалась ?
Вот и мне не нравится.
← →
Evgeny V © (2007-11-15 10:00) [232]
> Romkin © (15.11.07 09:30) [229]
И еще, если бы был язык со сборщиком мусора, но в котором были деструкторы, которые надо вызывать явно. Но в деструторе на самом деле только закрывались бы дескрипторы файлов, битмапов и т.п - если это объект такого типа. А в другом случае на самом длеле ничего бы не делалось, все оставалось бы И ты например об этом не знаешь (так сказать эмуляция дельфи не для .NET) Тебя такое устроило бы? То есть что тебе точно не нравится? Непривычная методика работы или ты против того, что память где-то некоторое время болтается? C файлами - ну я например не знаю как автоматом освободить гарантированно файл.... Не додумали они тут LOL
← →
Игорь Шевченко © (2007-11-15 10:01) [233]Romkin © (14.11.07 21:58) [188]
> А зачем? Просто налагай штраф за try/except, если не обосновано.
Проще немцев импортировать
← →
Romkin © (2007-11-15 10:34) [234]Evgeny V © (15.11.07 10:00) [232]
> И еще, если бы был язык со сборщиком мусора, но в котором
> были деструкторы, которые надо вызывать явно. Но в деструторе
> на самом деле только закрывались бы дескрипторы файлов,
> битмапов и т.п - если это объект такого типа. А в другом
> случае на самом длеле ничего бы не делалось, все оставалось
> бы И ты например об этом не знаешь (так сказать эмуляция
> дельфи не для .NET) Тебя такое устроило бы?
Посмотри внимательно на отрывок, что я привел: меня устраивает и такое :)
В идеале в java меня устроило бы наличие интерфейса, экспонирование которого объектом говорило бы виртуальной машине (ей, а не вызывающей стороне!) о том, что нужно дернуть метод этого интерфейса, как только и сразу на него перестанут ссылаться. Все.
Другими словами, пусть есть предопределенный интерфейс IDispose (sic!) с одним методом Close. И есть следующий контракт: если объект владеет ресурсами, которые надо освобождать сразу, он обязан экспонировать этот интерфейс, и в реализации Close должен быть код их освобождения. Система (VM, но никак не вызывающая сторона!) обязуется, в случае, если у объекта экспонируется этот интерфейс, вызвать его метод Close как можно быстрее после момента, когда на объект перестали ссылаться.
Неужели это сложно? При этом тот, кто будет использовать этот объект, может вообще не догадываться о наличии у него IDispose, это забота системы.
← →
Юрий Зотов © (2007-11-15 10:48) [235]> Romkin © (15.11.07 10:34) [234]
О! То, что нужно. И нужно было сделать. Сразу. Тем более, что делается элементарно.
← →
Юрий Зотов © (2007-11-15 10:49) [236]> Romkin © (15.11.07 10:34) [234]
Видимо, именно поэтому в дотнете и ввели IDisposable, учтя недочеты джавы.
← →
Evgeny V © (2007-11-15 11:09) [237]
> Romkin © (15.11.07 10:34) [234]
> Неужели это сложно?
Не знаю, наверное да... Вопрос, который мог бы решаться по разному.
А зачем удалять объект из памяти (уже не нужный), если он никому не мешает? Проще наверное удалить сразу кучу объетов, тем более память освобождаем страницами, блоками... и т.п. Связано думавю с оптимизацией работы GC. Отсюда наверное и ноги растут того, что объект не нужен, но как бы есть в памяти(что наблюдаем и у компиляторов дельфи, с++ при обращении к их менеджерам памяти). А удаление(закрытие) дескрипторов файлов -ну так оно такое же по сути как и в дельфи. Так в чем разница? Правила оформления. И более толстая прослойка между ОС и приложением. Но правила меняются от платформы к платформе. А вот идея GC мне в общем нравится. В BlackBox например как ты и хочешь нет IDIsposable для пользователя. Там правда и нет явного удаления объекта(там и идеология ООП несколько другая). А вот файл надо закрывать все равно ручками и последовательный порт. На мой взгляд проблема в определении того, что объект уже не нужен. Это не делается сразу. А потому повторноиспользуемые ресурсы могут не стать такими, если на некоторое время "подвиснут" в системе.
Резюме - или мы сами дергаем интерфейсы когда нам надо, или приходится мириться с недетерминированостью процесса удаления объекта. Некоторое разрастание используемой памяти считается злом небольшим, а потому явно можно не удалять ресурсы связанные с памятью. А вот файлы - это повторно используемый ресурс, который может быть нужен прямо сейчас, а потому мы должны как можно быстрее его освободить(ручной метод).
А что выбирать и когда - зависит от задачи, требований начальства, денег, времени и собственных предпочтений:-)
PS:
Я в общем не ставил задачу убедить кого-либо, что JAVA - это супер.
Я только хотел сказать, что в JAVA полагаться на вызов finlize нельзя. И если этого не знать, то конечно можно долго ругать систему, язык и прочее:-)
← →
DiamondShark © (2007-11-15 11:26) [238]
> А зачем мне вообще об этом думать? Если меня добрая Виртуальная
> машина избавляет от дум о памяти - пусть освободит и от
> дум о ресурсах!
С чего вдруг такая маниловщина?
← →
Romkin © (2007-11-15 11:32) [239]Evgeny V © (15.11.07 11:09) [237] Да, все правильно. Есть ли на объект ссылки - определяет сборщик мусора, когда набредает на этот объект. Ничего не имею против, эта идеология вполне имеет право на жизнь.
Но почему не выделена "каста" объектов, которые должны освобождать внешние ресурсы как можно быстрее - вот в чем вопрос.
Причем препятствий особых и нет: в [234] я ни слова не сказал об освобождении памяти, я говорил о дергании метода, а не о наличии деструктора.
Во-первых, много таких объектов не будет, во-вторых, они, как правило, "медленные" (это не память, на памяти уже дворник сидит!). Так что особо мешает подшивать для таких вот объектов отслеживание ссылок по месту? Когда ссылки исчезли - дергаем Close, ну а дальше по ситуации: можно пометить объект как неиспользуемый, чтобы когда на него набредет GC, он его особо не терзал, а можно и не делать ничего :)
← →
Однокамушкин (2007-11-15 11:38) [240]
> Так что особо мешает подшивать для таких вот объектов отслеживание
> ссылок по месту? Когда ссылки исчезли - дергаем Close,
Мешает то, что счётчик ссылок работает только для простых типов вроде string-ов, а когда есть циклические ссылки двух объектов друг на друга и больше никаких, счётчик ссылок не поможет, тут нужен более сложный алгоритм определения того, что на объекты нет доступных извне ссылок - тот самый алгоритм, который и реализует GC
← →
Romkin © (2007-11-15 11:41) [241]
> Мешает то, что счётчик ссылок работает только для простых
> типов вроде string-ов, а когда есть циклические ссылки двух
> объектов друг на друга и больше никаких, счётчик ссылок
> не поможет, тут нужен более сложный алгоритм определения
> того, что на объекты нет доступных извне ссылок - тот самый
> алгоритм, который и реализует GC
Почему-то в COM этому ничего не мешает.
← →
Piter © (2007-11-15 11:44) [242]Romkin, а почему FreeLibrary не приводит к мгновенной выгрузке библиотеки?
А почему даже завершение процесса, который единственный использует некую библиотеку - не приводит мгновенно к выгрузке этой библиотеки физически из памяти?
Ведь по той же логике - при обнулении количества ссылок на библиотеку - она должна уничтожаться, это запротоколировано Microsoft. А на самом деле это не так. Вывод - Windows хреновая операционная система.
Юрий Зотов © (15.11.07 2:48) [220]
Миш, ты никак не мог лучше подтвердить мои слова о том, что ты не вполне понимаешь, что такое ресурсы
о, да. Я вообще ламер ;)
Юрий Зотов © (15.11.07 2:48) [220]
Какие сборщики мусора будут тебе хэндлы закрывать?
хэндл - такой же нетипизированный объект, просто число - одной windows и системным таблицам в ВАП процесса известно к чему это относится. Ну и логике программиста, если он не забудет откуда это число.
А в Java не должно быть никаких хендлов.
← →
Evgeny V © (2007-11-15 11:50) [243]
> Юрий Зотов © (15.11.07 10:49) [236]
IDispoSible не спасет, все равно надо явно вызывать Close или Dispose. В JAVA
есть методы Dispose, Close, есть интерфейс CloseAblr. Для своих классов сделать интерфейс не проблема. Все равно надо вызывать и там и там, если хотите немедленного освобождения ресурсов.
> Romkin © (15.11.07 11:32) [239]
Ей богу не знаю, я бы не был против, если бы это было быстро:-)
← →
DiamondShark © (2007-11-15 11:56) [244]
> Система (VM, но никак не вызывающая сторона!) обязуется,
> в случае, если у объекта экспонируется этот интерфейс,
> вызвать его метод Close как можно быстрее после момента,
> когда на объект перестали ссылаться.
> Неужели это сложно?
Давай смотреть.
1. В методе Close доступен this, а это значит, что побочным эффектом метода Close может стать то, что на объект снова начнут ссылаться. Что должна делать система в этом случае?
2. С учётом (1) в многопоточном окружении объект может сколько угодно раз становиться доступным и недоступным, параллельно с выполнением метода Close. Что должна делать система в этом случае?
3. В момент обнаружения недоступности объекта как поток, создавший объект, так и поток, обнуливший последнюю ссылку могут уже не существовать. В контексте какого потока будет выполняться метод Close? Как скажется на ресурсах их выделение и освобождение в контексте разных потоков? Что делать с ресурсами, которые не допускают освобождение в контексте потока, отличного от создающего (например, window handle)?
4. Подсчёт ссылок не гарантирует освобождение объекта, существует проблема циклических ссылок, поэтому GC использует другой метод определения доступности объекта. В какое место алгоритма GC встроить вызов метода Close?
← →
Romkin © (2007-11-15 11:59) [245]
> Romkin, а почему FreeLibrary не приводит к мгновенной выгрузке
> библиотеки?А почему даже завершение процесса, который единственный
> использует некую библиотеку - не приводит мгновенно к выгрузке
> этой библиотеки физически из памяти?
Ты мелкое с мягким не путай :)
У тебя получается - в огороде бузина а в Киеве дядька.
Да, в java нет хендла. И слава богу. Там есть Stream, объект. Так почему я должен сам определять момент, когда он мне становится не нужен, и вызывать его метод Close?
И что, по-твоему, внутри этого объекта Stream нет хендла? Я сильно сомневаюсь. Он есть, может быть, где-то поглубже. И хендл это или объект - сути не меняет. Можешь считать, что объект держит файл.
Я хочу, чтобы некоторые ресурсы освобождались сразу, как только становятся не нужны. Встроенного механизма для этого в java нет. Все. О чем дальнейший разговор-то?
← →
DiamondShark © (2007-11-15 12:03) [246]
> Romkin © (15.11.07 11:41) [241]
>
> Почему-то в COM этому ничего не мешает.
Очень мешает. Повисшие циклические ссылки могут сильно насолить. Зависнут два объекта, занявшие ресурсы, и привет.
Попишите подольше на чём-нибудь не просто время от времени использующем COM, а прямо таки пропитанным им насквозь.
Вроде Акцесса.
← →
@!!ex © (2007-11-15 12:04) [247]> [246] DiamondShark © (15.11.07 12:03)
Пишу на DirectX. Все на COM.
Проблем нет.
← →
DiamondShark © (2007-11-15 12:05) [248]
> Я хочу, чтобы некоторые ресурсы освобождались сразу, как
> только становятся не нужны.
Вызывай Close. В чём проблема? Лень пять букв написать?
← →
Evgeny V © (2007-11-15 12:06) [249]DiamondShark © (15.11.07 11:56) [244]
3. В момент обнаружения недоступности объекта как поток, создавший объект, так и поток, обнуливший последнюю ссылку могут уже не существовать. В контексте какого потока будет выполняться метод Close? Как скажется на ресурсах их выделение и освобождение в контексте разных потоков? Что делать с ресурсами, которые не допускают освобождение в контексте потока, отличного от создающего (например, window handle)?
← →
Evgeny V © (2007-11-15 12:07) [250]Дополнение к Evgeny V © (15.11.07 12:06) [249] - этот пункт как раз таки решен - у GC свой поток
← →
DiamondShark © (2007-11-15 12:08) [251]
> @!!ex © (15.11.07 12:04) [247]
А я за всю жизнь не видел ни одного китайца живьём.
Значит ли это, что китайцев нет?
← →
DiamondShark © (2007-11-15 12:10) [252]
> этот пункт как раз таки решен - у GC свой поток
Решён он будет тогда, когда скажут, что делать с ресурсами, которые нельзя освобождать в потоке, отличном от создавшего.
← →
Dimka Maslov © (2007-11-15 12:12) [253]Если паскаль – язык для начинающих, тогда java – для заканчивающих.
← →
Romkin © (2007-11-15 12:13) [254]DiamondShark © (15.11.07 11:56) [244]
Что-то мне подсказывает, что ответы уже есть в .NET
Замечу, что для "ручного" вызова метода close существуют практически те же проблемы.
← →
Romkin © (2007-11-15 12:15) [255]DiamondShark © (15.11.07 12:05) [248] Ты не читаешь, что пишет, например, Зотов?
← →
DiamondShark © (2007-11-15 12:19) [256]
> Romkin © (15.11.07 12:13) [254]
> Что-то мне подсказывает, что ответы уже есть в .NET
Нет.
Дотнетовский IDisposable работает не так.
> Замечу, что для "ручного" вызова метода close существуют
> практически те же проблемы.
Да-а?! Ну, пусть так. Тогда и для ручного вызова деструктора в дельфях и плюсах "существуют практически те же проблемы", потому что классический деструктор и метод close ничем не отличаются.
Тогда вопрос: так в чём же, блин, суть претензий?
← →
DiamondShark © (2007-11-15 12:21) [257]Удалено модератором
Примечание: Выражения выбираем
← →
@!!ex © (2007-11-15 12:24) [258]> [257] DiamondShark © (15.11.07 12:21)
Тем что после вызова Close остается вполне рабоий объект без данных, которые были убиты Close.
После Destroy ничего не остается.
← →
Romkin © (2007-11-15 12:29) [259]
> Да-а?! Ну, пусть так. Тогда и для ручного вызова деструктора
> в дельфях и плюсах "существуют практически те же проблемы",
> потому что классический деструктор и метод close ничем
> не отличаются.Тогда вопрос: так в чём же, блин, суть претензий?
>
В том, что, понимаешь, в Delphi я могу сам управлять временем жизни объекта. А в java у меня этой возможности просто нет. Ее вырубили. И этим, простите, создали проблему. Какую - см. посты Зотова, мне кажется, он толково ее обозначил.
Недоделка.
Почему в Delphi я могу писать в стиле [229], а в java - нет?
Заметь, в приведенном коде нет ни вызова close, ни вызова деструктора. При этом все работает, млин. И не то что в разных потоках, в разных приложениях.
← →
Игорь Шевченко © (2007-11-15 12:30) [260]Romkin © (15.11.07 12:29) [259]
Писать надо на ассемблере. На худой конец - на Прологе.
← →
Romkin © (2007-11-15 12:31) [261]
> Тем что после вызова Close остается вполне рабоий объект
> без данных, которые были убиты Close.После Destroy ничего
> не остается.
Верно. Но после Close должен оставаться вполне рабочий объект, на который нет ссылок. Объект, к которому нельзя обратиться.
← →
Юрий Зотов © (2007-11-15 12:35) [262]> Romkin © (15.11.07 12:29) [259]
Ром, бесполезно. Иногда бесполезно. И ты знаешь, почему.
← →
@!!ex © (2007-11-15 12:57) [263]"Приходя на кухню, каждую неделю видя переполненную сахарницу и рассыпанный вокруг неё сахар удивлялся, а тут вдруг осенило: вокруг меня на этаже только Java девелоперы -нету привычки ни выделять достаточно места под буффер перед его заполнением, ни удалять за собой использованные объекты."(С) БОР
← →
clickmaker © (2007-11-15 13:07) [264]Java девелоперам вообще не сладко.
Смотрите, какой мизер им предлагают. Хорошо, хоть сахар бесплатно
Senior Java developer
Город: Санкт-Петербург
Работодатель: Sunrise-r SPb
Уровень зарплаты: от 40 до 45 руб.
← →
palva © (2007-11-15 13:11) [265]вокруг меня на этаже только Java девелоперы
У Delphi- или Basic-разработчиков тоже нет нужды думать о буферах при работе со строкой. Наверно поэтому слишком часто приходится видеть неэффективный код связанный с созданием и удалением промежуточных строк при всякого рода динамических конструированиях строк. Некоторые программисты используют для подобного конструктора самодельную домашнюю заготовку - что-то вроде StringBuilder в .NET Но начинающие как правило этим не заморачиваются, а педагоги и не советуют. Ибо нестандартно.
← →
Piter © (2007-11-15 13:15) [266]Romkin © (15.11.07 11:59) [245]
И что, по-твоему, внутри этого объекта Stream нет хендла? Я сильно сомневаюсь
ну внутренняя реализация тебя касаться не должна.
Romkin © (15.11.07 11:59) [245]
Так почему я должен сам определять момент, когда он мне становится не нужен, и вызывать его метод Close?
можешь не вызывать.
Если ты повторно откроешь этот файл из Java - он уже не откроется по причине занятости разве?
Romkin © (15.11.07 11:59) [245]
Я хочу, чтобы некоторые ресурсы освобождались сразу, как только становятся не нужны
вызывай Close. В чем проблема то?
По сути, тебе не нравится то, как работает сборщик мусора в java. Но он работает не так, как ты хочешь в свете аспекта освобождения ресурсов, а по другим критериям. Поэтому я привел пример с FreeLibrary, ты может и хочешь, чтобы DLL выгрузилась сразу при обнулении ссылок, но windows из своих расчетов так не работает. Вот и все. И методов стопроцентно выгрузить библиотеку из памяти нету.
Romkin © (15.11.07 12:29) [259]
в Delphi я могу сам управлять временем жизни объекта. А в java у меня этой возможности просто нет
вот именно. Потому что java - язык с самостоятельным управлением жизнью объекта и сборщиком мусора. Не нравится такой подход - пожалуйста, не используй, в чем проблема?
По-моему, это все равно что говорить, ассемблер - говно, так как в нем нет ООП.
← →
Romkin © (2007-11-15 13:21) [267]
> ну внутренняя реализация тебя касаться не должна.
Вот именно! К этому, собственно, и стремлюсь. Но тут-то меня она касается, потому что я должен знать, что надо вызвать метод Close.
Замечаешь логику? Для того, чтобы удачно использовать такой объект, я должен обладать информацией о его внутреннем устройстве, пусть и опосредованной!
Иначе как трактовать фразу: "Чтобы объект освободил ресурс, ты должен вызвать метод Close"? Опаньки! По-твоему, это не информация о внутреннем устройстве объекта?
← →
DiamondShark © (2007-11-15 13:24) [268]
> Romkin © (15.11.07 12:29) [259]
Ладно. Давай разбираться.
Вспомним для начала турбо паскаль. Там объекты вообще не обязаны были иметь какой-либо деструктор. Могли никакого не иметь. И операции управления памятью и инициализации/финализации объекта были разделены: были операторы New и Dispose, наряду с конструкторами/деструкторами.
Зотов сначала сказал, что это именно автоматическое управление памятью мешает ему работать. Но это -- [выбранное выражение], потому что если б он свою задачу в такой же постановке (есть куча объектов непоймикакого класса) решал на турбо паскале, у него бы возникла точно такая же проблема: неизвестно, чего у объекта вызывать для освобождения, потому что как называется деструктор и есть ли он вообще -- неизвестно.
Вывод: ни GC, ни вообще какой иной протокол управления памятью тут совершенно ни при чём.
Fixed?
("Доверили бы вы аэропорт программе на турбопаскале")
Между прочим, у стримов в TurboVision был метод Close, потому что объекты в турбопаскале можно было создавать не только в куче, но и статически и на стеке, а деструкторов могло быть сколько угодно, в том числе и ноль. Да и оператор Dispose можно было вызвать без указания деструктора.
Опять видим, что процедура управления памятью к освобождению ресурсов имеет отношение весьма слабое.
Идём дальше.
Как писали на турбопаскале? А первым делом создавали класс с пустым виртуальным деструктором, и от него наследовали всё остальное. Иными словами сами руками создавали себе нужный интерфейс. Это оказалось настолько продуктивным, что Борланд сначала включил такой объект в библиотеку TurboVision, а потом вообще вынес на уровень языка.
Почему в языках с ручным управлением памятью так важно наличие виртуального (или по умолчанию, как в плюсах) деструктора? А именно для того, чтобы иметь возможность удалять граф взаимно ссылающихся объектов! Это единственно возможный способ освободить память, без виртуального деструктора вообще невозможно было бы программировать с использованием таких объектов. Именно это обстоятельство обусловило тот факт, что все объекты в языках с ручным управлением памятью снабжены интерфейсом, содержащим виртуальный деструктор.
Возможность навесить на деструктор ещё что-то, кроме освобождения взаимных ссылок, явилась приятным, но совсем не обязательным бонусом.
Однако, дельфисты, видимо, настолько привыкли к совмещению операций управления памятью и инициализации/финализации объекта, что стали считать это не одной из возможностей, а чем-то вроде священной истины.
С появлением автоматического управления памятью отпала и необходимость в средстве для ручного освобождения взаимных ссылок, а вместе с этим весма сомнительной стала и необходимость интерфейса виртуального деструктора, по крайней мере, необходимость его безусловного наличия. Действительно, зачем он нужен, если в большинстве случаев так и останется пустым?
А кому очень надо, сам реализует абстрактный ксласс с нужным интерфейсом и от него унаследует всю иерархию своих ресурсозахватывающих классов.
← →
Romkin © (2007-11-15 13:31) [269]
> Однако, дельфисты, видимо, настолько привыкли к совмещению
> операций управления памятью и инициализации/финализации
> объекта, что стали считать это не одной из возможностей,
> а чем-то вроде священной истины.
Брр! Я речь разве об этом вел? Или Зотов?
> А кому очень надо, сам реализует абстрактный ксласс с нужным
> интерфейсом и от него унаследует всю иерархию своих ресурсозахватывающих
> классов.
Вот именно. Сам. То есть, к управлению памятью меня вообще не допускают, а остальное - сугубо сам, ручками? И если не предусмотрел - пеняй на себя?
И при этом, замечу, частично снимается покров тайны с реализации: для успешного использования класса программист должен хотя бы частично знать его внутреннее устройство.
← →
DiamondShark © (2007-11-15 13:33) [270]
> Опаньки! По-твоему, это не информация о внутреннем устройстве
> объекта?
Это информация об интерфейсе объекта.
Тебя ж не смущает необходимость знания, вроде: "Для того, чтобы нарисовать буковки, надо вызвать метод DrawText".
Ты так разошёлся, что скоро тебя не удовлетворит ничего меньшее, как объект, который после вызова конструктора делает всё, что он телепатически от тебя узнал, а потом самоуничтожается.
Кстати, конструктор тут тоже лишняя сущность. Пусть VM сама разбирается, что ты захотел.
← →
Romkin © (2007-11-15 13:39) [271]Поясню, опять же на примере с потоками:
function BigBrother.GetMeTheData: IStream;
begin
//Что здесь?
end;
//Пользуем, где-то:
procedure ReadFile;
var
Stream: IStream;
begin
Stream := BigBrother.GetMeTheData;
Stream.Read(...);
//Big thanks!
end;
Вот что у меня может быть в первой функции? Я могу взять поток от адаптера, захватив файл, могу - через вызов GetStreamOnHGlobal дать кусок памяти, могу свой объект сделать, который данные на лету создавать будет.
Вызывающая сторона знает, что там внутре? Нет. Совсем. И не ее это забота. Более того: ей запрещено вообще делать предположения о том, где лежит данный ей объект и как он устроен.
Вот именно это и называется полной капсуляцией.
← →
Romkin © (2007-11-15 13:43) [272]
> Это информация об интерфейсе объекта.Тебя ж не смущает необходимость
> знания, вроде: "Для того, чтобы нарисовать буковки, надо
> вызвать метод DrawText".
Э, нет. Дергание Close нужно тому объекту, который ты используешь, но никак не тому, который его использует: ему-то какой с этого прок? Ресурсы не его!
А вот DrawText нужен именно использующему объекту.
Слушай, ты действительно не понимаешь, о чем речь?
← →
DiamondShark © (2007-11-15 13:47) [273]
> Romkin © (15.11.07 13:31) [269]
>
> Брр! Я речь разве об этом вел? Или Зотов?
А чего вы так привязались к деструкторам? Как будто виртуальный деструктор и виртуальный метод close чем-то формально отличаются, кроме того, что деструктор в эпилоге обращается к менеджеру кучи.
> Вот именно. Сам.
Ну извини. В Дельфи нужный интерфейс реализовал дядя, а тут тебя напрягли.
Посчитай в каком-нибудь более-менее объёмном проекте количество классов, захватывающих ресурсы отличные от памяти, и сам реши, должен ли кто-то напрягаться, чтоб решить 1% твоих личных проблем.
Прими во внимание, также, тот факт, что объекты, типа, стримов, дбконнектов и прочих сокетов (т.е. 99.9% всех ресурсозахватывающих объектов) либо используются по сценарию открыл-поюзал-закрыл, либо находятся по хорошо известным на момент разработки специфически типизированным ссылкам, т.е. не вписываются в зотовский сценарий "куча объектов непойми-какокого класса".
Ну и из-за чего вы с Зотовым подняли гевулт? Зотов на высосанном из пальца "реальном примере" дизайна задней ногой, а ты -- вообще на пустом месте.
← →
Romkin © (2007-11-15 13:52) [274]
> Ну и из-за чего вы с Зотовым подняли гевулт? Зотов на высосанном
> из пальца "реальном примере" дизайна задней ногой, а ты
> -- вообще на пустом месте.
Хм. Класс в java должен заботиться о сохранности ресурсов другого класса. Инкапсуляция разлетается вдребезги. Действительно, пустое место и остается.
← →
DiamondShark © (2007-11-15 13:53) [275]
> Romkin © (15.11.07 13:39) [271]
Я в дотнете пишу
using (Stream stm=BigBrother.GetMeTheData())
{
stm.Read(...);
stm.Read(...);
}
В яве будет try...finally c close.
Весь шум из-за двух строчек кода?
← →
DiamondShark © (2007-11-15 13:57) [276]
> Romkin © (15.11.07 13:52) [274]
> Хм. Класс в java должен
Не класс, а программист.
У тебя есть контракт класса, в котором сказано: уходя гасите всех.
В чём проблема?
Вот еслиб у тебя был класс не с методом
DrawText(x, y, str)
а с парой
MoveTo(x, y);
DrawText(str);
ты бы тоже стал возмущаться "А! Меня заставляют знать о каких-то там текущих x, y!"?
← →
DiamondShark © (2007-11-15 13:58) [277]
> Инкапсуляция разлетается вдребезги
Угу. Вместе с боингами в аэропорту.
Без истерик можно?
← →
Черный Шаман (2007-11-15 14:37) [278]
> Юрий Зотов © (15.11.07 02:44) [219]
>
> > Черный Шаман (15.11.07 01:50) [215]
>
> В [80] я привел код теста, который показывает, что finalize
> не вызвался ни разу за все время жизни приложения (хотя
> счетчик ссылок на объект обнулялся, как минимум, дважды).
> Как это понимать? Очевидно, так, что за все время жизни
> приложения GC ни разу не решил, что пора почистить память.
> По крайней мере, других объяснений нет.
>
> Но возникает вопрос - а если бы объект открыл файл или коннект
> к БД, а код его освобождения был прописан именно в finalize
> (кстати, в полном соответствии с рекомендациями документации)
> то что, этот ресурс так и остался бы открытым? Чушь ведь.
Нет не чушь. Хотите более детерминированного освобождения сами вызывайте GC, хотя это делфийский вариант "прогнать все переменные".
GC вызывается не когда угодно, а когда не хватает свободной памяти.
← →
Юрий Зотов © (2007-11-15 15:00) [279]> Черный Шаман (15.11.07 14:37) [278]
>> Но возникает вопрос - а если бы объект открыл файл или коннект
>> к БД, а код его освобождения был прописан именно в finalize
>> (кстати, в полном соответствии с рекомендациями документации)
>> то что, этот ресурс так и остался бы открытым? Чушь ведь.
> Нет не чушь.
Чи-го? Программа завершилась, ресурс остался открытым - и это не чушь?
Нет, вот с ЭТИМ я уж точно спорить не стану.
← →
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. Ну ссылаюсь я на него, дальше что?
← →
Piter © (2007-11-15 17:55) [321]Юрий Зотов © (15.11.07 17:38) [312]
я человек крайне вежливый, поэтому не могу не отвечать на посты, прямо мне адресованные. Поэтому, если ты хочешь, чтобы я на них не отвечал, то ты их просто не пиши, ладно?
а у меня такая же фигня. Значит, мы уйдем в рекурсию? ;)
И вы лукавите, я не говорил, что не хочу чтобы вы отвечали. Я говорил, что хочу, чтобы вы отвечали более конкретно, чем констатация того, что я чего-то не знаю. Особенно в свете того, что я это знаю..
Юрий Зотов © (15.11.07 17:38) [312]
то хотя бы разберись сначала, почему бывают такие программы, что если ее запустить сто раз (каждый раз завершая), то на сто первый окажется, что ресурсы системы кончились
а вы правда считаете, что я этого не знаю? Тогда я в ваших глазах полный нуб, я бы на вашем месте даже не стал бы тратить время на объяснение таких тем человек, который по-моему мнению такой новичок.
Юрий Зотов © (15.11.07 17:38) [312]
А еще разберись с тем, почему бывает невозможно удалить файл, хотя программа, которая его юзала, уже завершилась
а вот это для меня новость. Если этот файл никакая другая программа также не использует - он полюбому должен удалиться (если достаточно прав на удаление).
Windows поддерживает полную сборку мусора от завершившегося процесса, по крайней мере в идеале должна поддерживать.
Поэтому тут пример не очень, на мой взгляд.
← →
Eraser © (2007-11-15 17:56) [322]
> Игорь Шевченко © (15.11.07 17:51) [319]
> Ну и со сброкой мусора тоже самое.
не то же самое, о чем и спор на 17 страниц ))
да и не отбирал никто у разработчика возможность присваивать строке пустое значение в конце работы с ней.
← →
Порш (2007-11-15 17:56) [323]Извините, что вмешиваюсь в вашу высоконаучную беседу, но....
Из того что я понял из работы сборщика мусора, я выделил для себя следующее (.Net):
Если я хочу сам освободить занятые объектом ресурсы, я использую Dispose(). Если не вызывать этот метод, можно прописать код освобождения в finalize(). Уж он то будет точно вызван, хоть и при закрытии приложения, а значит утечки не будет. Если он не вызыватется в процессе работы приложения, значит ему (приложению) хватает памяти и GC не вызывается.
В чем проблема-то?
← →
umbra © (2007-11-15 17:57) [324]
> "чтобы собирать мусор"
так а файлы он чего не закрывает то?
← →
Германн © (2007-11-15 17:58) [325]
> Piter © (15.11.07 17:55) [321]
> а вот это для меня новость. Если этот файл никакая другая
> программа также не использует - он полюбому должен удалиться
> (если достаточно прав на удаление).
>
Тем не менее бывает. Бывает и хуже.
← →
Юрий Зотов © (2007-11-15 17:59) [326]> Игорь Шевченко © (15.11.07 17:51) [319]
Про уши прочитал, но на что отвечать снова не нашел. Поэтому на уши не отвечаю.
Отвечаю на твое сравнение со строками. Оно некорректно, потому что строка не юзает unmanaged-ресурсов, а речь идет именно о них.
И только о них. А не о сборке мусора. К ней вопросов как раз нет, там все нормально.
← →
Piter © (2007-11-15 18:00) [327]Romkin © (15.11.07 17:44) [316]
О как!
Юра, помнишь, ты код с Stream приводил? Так вот: метод close ты вызывать не должен был! Нет у этого класса никаких ресурсов, которые не уберет сборщик мусора!
а что, если Close не вызвать - информация в файл не запишется, да? Как это например может быть, если не вызывать CloseHandle (или запишется частично).
← →
Eraser © (2007-11-15 18:01) [328]
> Порш (15.11.07 17:56) [323]
проблема в том, что может понадобиться явно вызвать destroy (уничтожить объект) в какой-то определенный момент N. В java такой возможности нет.
В C# - хз.
← →
Piter © (2007-11-15 18:03) [329]Германн © (15.11.07 17:58) [325]
Тем не менее бывает. Бывает и хуже
вряд ли. Бывает, что файл использует другая программа, вот и все.
← →
Piter © (2007-11-15 18:04) [330]Eraser © (15.11.07 18:01) [328]
проблема в том, что может понадобиться явно вызвать destroy (уничтожить объект) в какой-то определенный момент N
зачем? Не ссылайся больше на этот класс и забудь о нем.
← →
Юрий Зотов © (2007-11-15 18:05) [331]> Piter © (15.11.07 18:00) [327]
Миш, ответь точно, коротко и прямо на прямой вопрос - что такое unmanaged ресурсы?
← →
Порш (2007-11-15 18:06) [332]
> В C# - хз.
Как только нет на обьект ссылок, сборщик его соберет, а может и не соберет, если не собрал, значит таки опять не нужно. Что за мания такая собрать за собой. Это же не смертельно.
← →
Eraser © (2007-11-15 18:07) [333]
> Piter © (15.11.07 18:04) [330]
к сожалению в данный момент rtl и система устроены так, что если "не ссылаться больше на этот класс и забыть о нём", мы получим грабли, которые подробно описал ЮЗ. не правильно это, imho.
← →
Юрий Зотов © (2007-11-15 18:11) [334]> Порш (15.11.07 18:06) [332]
> Как только нет на обьект ссылок, сборщик его соберет
А файлы, которые этот объект держит открытыми, сборщик тоже закроет?
И заюзанные хэндлы объектов GDI - тоже освободит?
А открытые транзакции - тоже завершит? И коннекты к БД позакрывает?
← →
Порш (2007-11-15 18:13) [335]
> А файлы, которые этот объект держит открытыми, сборщик тоже
> закроет?
> И заюзанные хэндлы объектов GDI - тоже освободит?
> А открытые транзакции - тоже завершит? И коннекты к БД позакрывает?
>
Я же написал, это пропишем в finalize() - если даже в процессе работы сборщик и не соберет обьект и не вызовет этот метод, то при закрытии приложения - точно.
← →
Игорь Шевченко © (2007-11-15 18:14) [336]
> Отвечаю на твое сравнение со строками. Оно некорректно,
> потому что строка не юзает unmanaged-ресурсов, а речь идет
> именно о них.
Ну давайте от каждого класса будет требовать умения работать именно с такими ресурсами - а вдруг потомкам понадобится.
← →
@!!ex © (2007-11-15 18:14) [337]> [335] Порш (15.11.07 18:13)
Это не вариант.
Уже говорили.
Если надо файл еще раз открыть? А он еще не закрыт ниразу..
← →
clickmaker © (2007-11-15 18:14) [338]
> то при закрытии приложения - точно
а чего мелочиться? Может, при шатдауне винды все скопом и закроем? )
← →
Порш (2007-11-15 18:17) [339]
> а чего мелочиться? Может, при шатдауне винды все скопом
> и закроем? )
Я к тому, что после закрытии приложения все освободится и не будет висеть.
> Если надо файл еще раз открыть? А он еще не закрыт ниразу.
> .
А еще есть мягкие ссылки, там вообще обьект можно вернуть к жизни после смерти...
← →
Игорь Шевченко © (2007-11-15 18:18) [340]И в java и в .Net файлы как-то закрываются, не так ли ? Значит и "аппарат есть". Зачем требовать наличие этот аппарата у всего, чего только можно - не понимаю.
← →
Юрий Зотов © (2007-11-15 18:19) [341]> Порш (15.11.07 18:13) [335]
> то при закрытии приложения - точно.
Нет, не точно. finalize может быть вызван, а может быть и нет. Это уж как сборщик решит. А как он это решает - никому не ведомо. И даже дока вызова finalize тоже не гарантирует. Что мы и наблюдали на практике (см. выше).
Поэтому может получиться, что объект успешно сборщиком подметен - после чего освободить заюзанные этим объектом ресурсы стало уже некому. И повисли они, родимые.
← →
clickmaker © (2007-11-15 18:19) [342]
> > Если надо файл еще раз открыть? А он еще не закрыт ниразу.
> > .
>
> А еще есть мягкие ссылки, там вообще обьект можно вернуть
> к жизни после смерти...
это вообще путаешь мягкое с теплым
← →
Черный Шаман (2007-11-15 18:19) [343]
> @!!ex © (15.11.07 18:14) [337]
>
> > [335] Порш (15.11.07 18:13)
>
> Это не вариант.
> Уже говорили.
> Если надо файл еще раз открыть? А он еще не закрыт ниразу.
> .
Ничто не мешает самому написать управляемый контейнер или глобальный предок контейнер и в спецификации проекта обязать всех наследовать свои классы от него.
← →
Порш (2007-11-15 18:22) [344]
>
> Нет, не точно. finalize может быть вызван, а может быть
> и нет. Это уж как сборщик решит. А как он это решает - никому
> не ведомо. И даже дока вызова finalize тоже не гарантирует.
> Что мы и наблюдали на практике (см. выше).
Что приводит к вызову метода Finalize
Метод Finalize объекта может быть вызван в результате одного из следующих
четырех событий.
• Заполнение поколения 0 Это событие намного чаще остальных приводит
к вызову метода Finalize, так как является естественным следствием выделения
новых объектов во время работы кода приложения.
• Явный вызов статистического метода Collect объекта System.GC Код мо-
жет напрямую запросить сбор мусора у CLR. Хотя Microsoft настоятельно не
рекомендует так поступать, порой имеет смысл, чтобы приложение заставило
CLR выполнить сбор мусора (об этом я расскажу ниже).
• Выгрузка домена приложения CLR Выгружая домен приложения, CLR счи-
тает, что ни один объект в нем не является корнем, и вызывает метод Finalize
у каждого объекта, созданного в AppDomain. О домене приложения см. главу 20.
• Закрытие CLR Корректно завершив свою работу, процесс также пытается
корректно завершить работу- CLR. При этом CLR считает, что ни один объект
не является корнем, и вызывает метод F i n a l i z e у каждого объекта, созданного
в управляемой куче.
Рихтер
← →
Юрий Зотов © (2007-11-15 18:23) [345]> Игорь Шевченко © (15.11.07 18:14) [336]
> Ну давайте от каждого класса будет требовать умения работать именно с
> такими ресурсами - а вдруг потомкам понадобится.
Не надо от каждлго класса. Надо ввести в самый базовый класс один, четко документированный виртуальный метод. Так, как это сделано в TObject.
И все проблемы. И об этом уже говорилось. Стоит быть внимательнее .
← →
Игорь Шевченко © (2007-11-15 18:26) [346]Юрий Зотов © (15.11.07 18:23) [345]
> Не надо от каждлго класса. Надо ввести в самый базовый класс
> один, четко документированный виртуальный метод. Так, как
> это сделано в TObject.
Про TObject уже тоже говорили.
> Стоит быть внимательнее .
И все-таки я не понимаю, как же разработчики-то мучаются ? Им же надо файлы закрывать...А судя по ветке, они, файлы, могут закрыться, могут не закрыться или могут закрыться неизвестно когда...
← →
Юрий Зотов © (2007-11-15 18:27) [347]> Черный Шаман (15.11.07 18:19) [343]
> Ничто не мешает самому написать...
Хорошее предложение. Действительно, ничто не мешает.
Только не об этом речь-то.
← →
@!!ex © (2007-11-15 18:29) [348]> И все-таки я не понимаю, как же разработчики-то мучаются
> ? Им же надо файлы закрывать...А судя по ветке, они, файлы,
> могут закрыться, могут не закрыться или могут закрыться
> неизвестно когда...
Видимо они пользуются собственноручно написанными аналогами Close, что здесь уже обсуждалось.
И когда это не работает уже тоже обсуждалось.
← →
Piter © (2007-11-15 18:32) [349]Юрий Зотов © (15.11.07 18:05) [331]
Миш, ответь точно, коротко и прямо на прямой вопрос - что такое unmanaged ресурсы?
неуправляемые ресурсы. В нашем контексте - это ресурсы, которыми код без явного вмешательства программиста управлять не может, потому как понятия не имеет что это. То ли просто число, то ли хэндл открытого файла.
Любой unmanaged ресурс - это слишком низкий уровень абстракции для java, если хотите - недостаточная для кросс-платформенности абстракция.
Eraser © (15.11.07 18:07) [333]
к сожалению в данный момент rtl и система устроены так, что если "не ссылаться больше на этот класс и забыть о нём", мы получим грабли, которые подробно описал ЮЗ. не правильно это, imho
какие грабли? Приведи конкретный пример
Юрий Зотов © (15.11.07 18:11) [334]
А файлы, которые этот объект держит открытыми, сборщик тоже закроет?
Во-первых, вы применили хитрость. Речь шла не о том, что СРАЗУ соберет, речь шла о том, что соберет вообще. Хотите прямо сейчас? Пользуйтесь определенным методом. В любом случае утечки ресурсов не будет.
во-вторых, а что, разве нет? Допустим, ваш класс имеет ссылку на файл (stream). Сборщик соберет ваш класс, потом и ссылку, да и файл потом закроет. Только никто не обещает вам, что это случится прямо вот сейчас. Хотите сейчас? Решение вам сказали.
@!!ex © (15.11.07 18:14) [337]
Если надо файл еще раз открыть? А он еще не закрыт ниразу..
интересная логика. А если ты открыл файл в винде, а потом опять его хочешь открыть - и не получится, это что - проблемы винды?
Или все таки тебе надо вызвать сначала CloseHandle, а потом опять открывать? Так вот и в Java надо сначала Close, а потом открывать заново.
clickmaker © (15.11.07 18:14) [338]
а чего мелочиться? Может, при шатдауне винды все скопом и закроем? )
а вот кстати это и есть истина. Именно при шатдауне и закроем. А может даже и при шатдауне не будем закрывать, сохраним все открытым, это называется уйти в спячку, на ноутбуке очень часто используемый режим работы, что плохого то? Физически мы закроем только тогда, когда не будет хватать ресурсов.
← →
Юрий Зотов © (2007-11-15 18:32) [350]> Игорь Шевченко © (15.11.07 18:26) [346]
> Про TObject уже тоже говорили.
Извини, но пришлось повторить.
> Стоит быть внимательнее .
> как же разработчики-то мучаются ? Им же надо файлы закрывать... А
> судя по ветке, они, файлы, могут закрыться, могут не закрыться или могут
> закрыться неизвестно когда...
Кстати, я на деле с таким чудом сталкивался. Java-программа (Eclipse 3.2, JRE 1.5.10). Программа запущена под соедой, она пишет файл и нормально завершается. А файл оказывается захвачен непонятно кем. Причем не всегда.
← →
Eraser © (2007-11-15 18:38) [351]
> Piter © (15.11.07 18:32) [349]
да пример с файлом тыщу раз приводили.. открываем файл в режиме OF_SHARE_EXCLUSIVE или же подсоединяемся к named pipe"у с лимитом подключений = 1, в деструкторе закрываем хэндл файл.
чем не пример.. если последовательно создать/якобы_уничтожить пару таких объектов, то при создании второго, с большой вероятностью, вылезет ошибка доступа.
← →
Piter © (2007-11-15 18:42) [352]Юрий Зотов © (15.11.07 18:19) [341]
Поэтому может получиться, что объект успешно сборщиком подметен - после чего освободить заюзанные этим объектом ресурсы стало уже некому. И повисли они, родимые
серьезно? Давайте рассмотрим, например, файлы.
Вы создали экземпляр Stream, поработали с ним и забили на него.
По вашим словам, настанет время и сборщиком мусора объект будет подметен, соответственно будет и подметен используемый экземпляр stream... И... Повисли? Вы хотите сказать, что после этого файл будет продолжаться оставаться заблокированным с точки зрения windows?
← →
Порш (2007-11-15 18:45) [353]
> Piter © (15.11.07 18:42) [352]
> Юрий Зотов © (15.11.07 18:19) [341]
> Поэтому может получиться, что объект успешно сборщиком подметен
> - после чего освободить заюзанные этим объектом ресурсы
> стало уже некому. И повисли они, родимые
>
> серьезно? Давайте рассмотрим, например, файлы.
>
> Вы создали экземпляр Stream, поработали с ним и забили на
> него.
> По вашим словам, настанет время и сборщиком мусора объект
> будет подметен, соответственно будет и подметен используемый
> экземпляр stream... И... Повисли? Вы хотите сказать, что
> после этого файл будет продолжаться оставаться заблокированным
> с точки зрения windows?
Если объект уничтожен сборщиком мусора, то finalize этого обьекта вызван 100%. Если не был вызван close или в finalize не освободили ресурс, то кто виноват ясно.
← →
Порш (2007-11-15 18:46) [354]
> Если объект уничтожен сборщиком мусора, то finalize этого
> обьекта вызван 100%. Если не был вызван close или в finalize
> не освободили ресурс, то кто виноват ясно.
Даже не так, если в finalize не оперделен для этого обьекта, то он и не вызывается.
← →
Piter © (2007-11-15 18:46) [355]только я бы хотел услышать комментарии от Юрия, он говорит что "повиснет ресурс"
← →
Джо © (2007-11-15 18:47) [356]> [353] Порш (15.11.07 18:45)
> Если объект уничтожен сборщиком мусора, то finalize этого
> обьекта вызван 100%. Если не был вызван close или в finalize
> не освободили ресурс, то кто виноват ясно.
Это вы о C#? А здесь, главным образом, обсуждают Java. По поводу finalize в Java см. выше.
← →
Piter © (2007-11-15 18:47) [357]кстати, также очень бы хотелось услышать комментарии на это:
Юрий Зотов © (15.11.07 17:38) [312]
А еще разберись с тем, почему бывает невозможно удалить файл, хотя программа, которая его юзала, уже завершилась
как я понимаю, Юрий говорит о том, что файл уже больше ни одной программой не используется, а удалить его нельзя. Я такого не встречал. Очень хочу комментарий, когда это возможно и почему.
← →
Джо © (2007-11-15 18:50) [358]> [352] Piter © (15.11.07 18:42)
> Юрий Зотов © (15.11.07 18:19) [341]
> Поэтому может получиться, что объект успешно сборщиком подметен
> - после чего освободить заюзанные этим объектом ресурсы
> стало уже некому. И повисли они, родимые
>
> серьезно? Давайте рассмотрим, например, файлы.
>
> Вы создали экземпляр Stream, поработали с ним и забили на
> него.
> По вашим словам, настанет время и сборщиком мусора объект
> будет подметен, соответственно будет и подметен используемый
> экземпляр stream... И... Повисли? Вы хотите сказать, что
> после этого файл будет продолжаться оставаться заблокированным
> с точки зрения windows?
Псевдокод.
someClass = new SomeClass (path);
someClass.Read...
someClass.Write...
// вот тут, если не закрыть файл path, открытый для эксклюзивного доступа
// случится хрень
someClass = new SomeClass (path);
someClass.Read...
someClass.Write...
// А когда он освободится -- бог его знает.
← →
Piter © (2007-11-15 18:53) [359]Джо © (15.11.07 18:50) [358]
интересно. Только я описал алгоритм действий и в конце задал вопрос. На вопрос отвечено не было, зато зачем-то приведен некий пример, говорящий о том, что сборщик мусора НЕ МОМЕНТАЛЬНО очищает мусор, даже если ссылку на него никто не использует. По-моему, с этим тут никто даже спорить не пытался.
← →
Piter © (2007-11-15 18:59) [360]Джо, а давай такой пример рассмотрим, на Delphi:
someClass := TFileStrean.Create...
someClass.Read...
someClass.Write...
// вот тут, если не закрыть файл, открытый для эксклюзивного доступа
// случится хрень
someClass = TFileStream.Create
someClass.Read...
someClass.Write...
здесь тебя почему-то не удивляет, что случится хрень? А вот с Java удивляет! К чему бы это?
← →
Черный Шаман (2007-11-15 19:02) [361]
> Piter © (15.11.07 18:47) [357]
>
> кстати, также очень бы хотелось услышать комментарии на
> это:
>
> Юрий Зотов © (15.11.07 17:38) [312]
> А еще разберись с тем, почему бывает невозможно удалить
> файл, хотя программа, которая его юзала, уже завершилась
>
> как я понимаю, Юрий говорит о том, что файл уже больше ни
> одной программой не используется, а удалить его нельзя.
> Я такого не встречал. Очень хочу комментарий, когда это
> возможно и почему.
Иногда бывают такие хитрые баги, когда Windows при падении проекта, отлаживаемого в Delphi не собирает все открытые им дескрипторы. Даже после закрытия Delphi. Почему это происходит неясно, но происходит очень редко.
Похоже это баг операционной системы.
← →
Piter © (2007-11-15 19:03) [362]Черный Шаман (15.11.07 19:02) [361]
Похоже это баг операционной системы.
это я вполне допускаю. Но Юрий говорил о том, что пока я не изучу этот вопрос - смысла разговаривать нет. Получается, я должен изучить то, что в ОС Windows есть баги?
← →
Юрий Зотов © (2007-11-15 19:06) [363]> Piter © (15.11.07 18:42) [352]
> Давайте рассмотрим, например, файлы
Миш, рассмотри коннект к БД Paradox и успокойся. Заодно это и будет комментарий по поводу повисания ресурса.
Кстати, ты в курсе, что если программа загрузила DLL, а потом не вызвала FreeLibrary, то эта DLL в текущей сессии системы уже не выгрузится никогда, даже после завершения всех юзающих ее программ? Потому что система будет считать ее используемой.
Кстати, ты в курсе, что если программа захватила объекты GDI и не освободила их, то они будут заняты и после завершения программы?
Кстати, ты в курсе, что объекты ядра тоже могут оказаться занятыми и после завершения программы, если она их не освободила?
Кстати, ты в курсе, что файл - это тоже объект ядра?
Ну и т.д.
> Порш (15.11.07 18:45) [353]
> Если объект уничтожен сборщиком мусора, то finalize этого обьекта
> вызван 100%. Если не был вызван close или в finalize не освободили
> ресурс, то кто виноват ясно.
Пожалуйста, ветку прочтите сначала. Хотя бы для того, чтобы стало ясно, что речь в ней идет о джаве, а не о дотнет. А еще там выше примеры есть, по поводу вызовов finalize, их тоже не мешало бы посмотреть.
← →
Юрий Зотов © (2007-11-15 19:16) [364]> Piter © (15.11.07 18:59) [360]
> здесь тебя почему-то не удивляет, что случится хрень? А вот с Java
> удивляет! К чему бы это?
Миш, ты некорректно перевел код с джавы на Delphi. Вот правильный перевод:
someClass := TFileStrean.Create...
someClass.Read...
someClass.Write...
someClass.Free; // Вот в чем фокус.
someClass = TFileStream.Create
someClass.Read...
someClass.Write...
А теперь тебя ничего не удивляет?
А меня удивляет. То, что ты так упорно споришь о том, в чем толком не разбираешься. Даже в элементарной джаве.
Извини, достал уже. Хватит, Миш, а?
← →
SergeR___ (2007-11-15 19:33) [365]StreamInput si;
try {
si = new FileInputStream("aaa");
si.read(...
} catch (...) {
} finally {
si.flush();
si.close(); // Чем отличается?!
}
try {
si = new FileInputStream("aaa");
...
или я слепой?!
← →
Джо © (2007-11-15 19:38) [366]> [365] SergeR___ (15.11.07 19:33)
> si.close(); // Чем отличается?!
Например тем, что у TStream может не быть Close (или Flush) и у его потомка TFileStream их нужно будет вводить :) Последствия этого — очевидны и я об этом рассуждать не стану.
← →
serger___ (2007-11-15 19:42) [367]public abstract class InputStream implements Closeable {
...
package java.io;
import java.io.IOException;
/**
* A <tt>Closeable</tt> is a source or destination of data that can be closed.
* The close method is invoked to release resources that the object is
* holding (such as open files).
*
* @version 1.4 03/12/19
* @since 1.5
*/
public interface Closeable {
/**
* Closes this stream and releases any system resources associated
* with it. If the stream is already closed then invoking this
* method has no effect.
*
* @throws IOException if an I/O error occurs
*/
public void close() throws IOException;
}
← →
Piter © (2007-11-15 19:43) [368]Юрий Зотов © (15.11.07 19:06) [363]
Миш, рассмотри коннект к БД Paradox и успокойся. Заодно это и будет комментарий по поводу повисания ресурса
зачем мне парадокс. Я вам задал КОНКРЕТНЫЙ вопрос про файлы в пику вашего разговора о подвисании ресурсов. Вы сделали вид, что этот вопрос не заметили. Ну что сказать ;)
Юрий Зотов © (15.11.07 19:06) [363]
Кстати, ты в курсе, что если программа загрузила DLL, а потом не вызвала FreeLibrary, то эта DLL в текущей сессии системы уже не выгрузится никогда, даже после завершения всех юзающих ее программ? Потому что система будет считать ее используемой.
Кстати, ты в курсе, что если программа захватила объекты GDI и не освободила их, то они будут заняты и после завершения программы?
Кстати, ты в курсе, что объекты ядра тоже могут оказаться занятыми и после завершения программы, если она их не освободила?
не в курсе. Я меня есть вот какой источник информации - фамилия у него Рихтер и вот что он пишет:
[b]Что происходит при завершении процесса:[/b]
1. Выполнение всех потоков в процессе прекращается
2. Все User- и GDI-объекты, созданные процессом, уничтожаются, а объекты ядра закрываются (если их не использует другой процесс)
3. Код завершения процесса меняется созначения STILL_ACTIVE на код, переданный в ExitProcess или TerminateProcess.
4. Объект ядра "процесс" переходит в свободное, или незанятое (signaled) состояние. Прочие потоки в системе могут приостановить свое выполнение вплоть до завершения даного процесса.
5. Счетчик объекта ядра "процесс" меньшается на 1.
Юрий, вы должны согласится, что это достаточно хороший источник, или нет? Я теперь не знаю кому верить. Я пока считаю, что Рихтер описал КАК ДОЛЖНА РАБОТАТЬ Windows, то - что задокументировано. Вы же скорее всего описали как в реальности это обстоит. И это можно назвать БАГАМИ WINDOWS (есть еще один вариант - вы неправы).
Так что вы от меня хотели? Вы хотите, чтобы я знал баги windows перед тем, как с вами разговаривать? Не кажется ли это несколько... мммм... неправильным?
Юрий Зотов © (15.11.07 19:16) [364]
someClass.Free; // Вот в чем фокус
Вот вот. А лучше фокус сделать вот так:
someClass.Close; // Вот в чем фокус.
someClass.Free;
Только уж так принято, что сам вызов деструктора и финализация класса вынесены в ОДИН метод. А java позволяет избавиться вот от этого:someClass.Free;
И в результате должно остаться это:
someClass.Close; // Вот в чем фокус.
а вы убрав СОВМЕЩЕННЫЙ метод говорите - "опля, а java то - хрень полная". Интересный подход! Вы от java требуете, чтобы вообще никакого метода не вызывалось, хотя для delphi не против, чтобы вызывался метод Free. И вы его вызываете, не забываете! А вот вызвать close сложно.
← →
oxffff © (2007-11-15 20:19) [369]Объяните пожалуйста вкраце что за спор,
а то перечитать 19 страниц я бы рад,
От поста к посту нить разговора теряется.
Вижу только один сплошной finalize.
Есть в JAVA аналог SuppressFinalize из .NET ?
← →
Джо © (2007-11-15 20:36) [370]> [369] oxffff © (15.11.07 20:19)
> Объяните пожалуйста вкраце что за спор,
Оооо... С этим могут возникнуть сложности :)
← →
Юрий Зотов © (2007-11-15 20:39) [371]> serger___ (15.11.07 19:42) [367]
Можно привести пример логгера, который:
- открывает файл в своем конструкторе;
- имеет метод записи переданной строки;
- закрывает файл, когда становится не нужен.
← →
Piter © (2007-11-15 20:52) [372]Юрий Зотов © (15.11.07 20:39) [371]
так что, получается Рихтер неправ?
← →
Юрий Зотов © (2007-11-15 21:22) [373]> Piter © (15.11.07 20:52) [372]
1. Ты просто его не дочитал. Почитай, что он пишет об аварийном завершении (которое программист тоже должен предполагать).
2. В теории система гарантирует освобождение каких-то (не всех) ресурсов и при аварийном завершении. На практике эти гарантии выполняются не всегда. Примеры тебе уже приводились, и не только мною.
← →
Плохиш © (2007-11-15 22:40) [374]
> oxffff © (15.11.07 20:19) [369]
> Объяните пожалуйста вкраце что за спор
Бесконечный цикл и никакого спора...
← →
iZEN © (2007-11-15 23:20) [375]
> Piter © (15.11.07 17:21) [305]
>
> В чем я с вами согласен, дядь Юра, так это в том, что нефиг
> вообще было включать в Java такое понятие как finalize,
> если оно имеет такой глючный механизм исполнения. Может
> выполнится, а может и нет, это считай говорит о том, что
> никакого кода туда лучше вообще не писать, а тогда и само
> понятие нафиг не нужно.
Золотые слова.
Кстати, Джошуа Блох в том же духе о finalize высказался. ;)
← →
iZEN © (2007-11-15 23:35) [376]
> Джо © (15.11.07 19:38) [366]
>
> > [365] SergeR___ (15.11.07 19:33)
> > si.close(); // Чем отличается?!
>
> Например тем, что у TStream может не быть Close (или Flush)
> и у его потомка TFileStream их нужно будет вводить :) Последствия
> этого — очевидны и я об этом рассуждать не стану.
Таки это предусмотрели в иерархии системных классов Java. ;)
← →
iZEN © (2007-11-15 23:42) [377]Разрешите подытожить тему.
Описние метода finalize в JavaDoc неного несоответствует действительности. В разных JVM переопределённый в потомках java.lang.Object полиморфный метод finalize не гарантирует своего выполнения никоим образом, вполне допуская возможные утечки памяти из-за неполностью разрушаемых GC объектов (например, в случае выброса заведомо неперехватываемых исключений в теле метода и захвата других ресурсов перед освобождением одних т.д.).
Такое глючное поведение метода finalize в контексте сборщика мусора известно давно и, похоже, программисты на него давно забили. Но Юрий Зотов, такой вот упёртый человечек, пытается нам внушить, что это НЕПРАВИЛЬНО и ТАК_ДЕЛА_НЕ_ДЕЛАЮТСЯ. Согласен. Но лично я ничего с этим поделать не могу.
Мир несовершенен.
← →
Юрий Зотов © (2007-11-16 00:35) [378]> iZEN © (15.11.07 23:42) [377]
Ну а раз обеспечить надежную работу метода finalize в контексте GC практически нереально, стало быть - что?
Стало быть, ошибочна сама его концепция. И этот заведомо глючный механизм должен быть помечен, как deprecated и постепенно предан забвению.
Это раз.
Но тогда возникает вопрос - если метод finalize объявить нерекомендуемым, то где же тогда освобождать неуправляемые ресурсы? Очевидно, в каком-то другом методе, больше негде. Но вместо того, чтобы отдавать это дело на откуп тысячам разработчиков и плодить зоопарк имен для одного и того же, по сути, метода (close, dispose, cleanup, ... продолжите сами) не лучше ли поступить иначе?
Либо ввести этот метод сразу в класс Object (вариант 1), либо объявить интерфейс IDisposable уже на уровне java.lang (вариант 2). Аналогично Cloneable. И все сразу становится просто и понятно. Я, как пользователь класса, в нужный мне момент либо просто дергаю этот метод (в варианте 1), либо сначала смотрю, реализует ли этот класс IDisposable (вариант 2).
Это два.
Как тут уже многие говорили, никому, конечно же, не влом вызвать метод освобождения ресурсов из своего кода. И это нормально. Ненормально другое - поскольку я не могу знать реализацию юзаемого мною чужого класса, то я не могу и знать, хавает ли этот класс неуправляемые ресурсы, или нет. Соответственно, мне неизвестно надо ли для этого класса вызывать какой-то его метод освобождения ресурсов, или не надо. А если надо, то спрашивается - а как же этот метод в этом классе называется?
В общем, бардак и зоопарк. Которого вполне можно было бы избежать, притом очень легко. И очень странно, что этого не было сделано сразу.
Вот об чем и весь сыр-бор, собственно.
← →
mephasm (2007-11-16 00:41) [379]Юрий Зотов © (16.11.07 00:35) [378]
Можно уменьшить скоуп ручного контроля за ресурсами, введя что-нибудь подобное LogManager в log4j. Конечно это приносит свои проблемы, но освобождает от других.
← →
iZEN © (2007-11-16 01:06) [380]
> Юрий Зотов © (16.11.07 00:35) [378]
> Либо ввести этот метод сразу в класс Object (вариант 1),
> либо объявить интерфейс IDisposable уже на уровне java.
> lang (вариант 2). Аналогично Cloneable. И все сразу становится
> просто и понятно. Я, как пользователь класса, в нужный мне
> момент либо просто дергаю этот метод (в варианте 1), либо
> сначала смотрю, реализует ли этот класс IDisposable (вариант
> 2).
Не, не пойдёт.
Концепция управляемого языка изменится, а это не входит в планы ни Sun, ни IBM, в общем, никого, кроме вас. ;) Зоопарк с новыми методами очистки будет продолжаться и с этим ничего поделать нельзя. Наверно, это к лучшему, но для вас это выглядит странно, поскольку на Java, ещё раз повторяю, нужно мыслить не в терминах Delphi — мир Java гораздо богаче и допускает наличие определённых глюков. :)
← →
Германн © (2007-11-16 01:27) [381]
> iZEN © (16.11.07 01:06) [380]
>
>
> > Юрий Зотов © (16.11.07 00:35) [378]
> > Либо ввести этот метод сразу в класс Object (вариант 1),
>
> > либо объявить интерфейс IDisposable уже на уровне java.
>
> > lang (вариант 2). Аналогично Cloneable. И все сразу становится
> > просто и понятно. Я, как пользователь класса, в нужный
> мне
> > момент либо просто дергаю этот метод (в варианте 1), либо
> > сначала смотрю, реализует ли этот класс IDisposable (вариант
> > 2).
>
> Не, не пойдёт.
> Концепция управляемого языка изменится, а это не входит
> в планы ни Sun, ни IBM, в общем, никого, кроме вас. ;) Зоопарк
> с новыми методами очистки будет продолжаться и с этим ничего
> поделать нельзя. Наверно, это к лучшему, но для вас это
> выглядит странно, поскольку на Java, ещё раз повторяю, нужно
> мыслить не в терминах Delphi — мир Java гораздо богаче и
> допускает наличие определённых глюков. :)
>
Еще раз хочу кое-что добавить. Насколько я понял посты ЮЗ, суть его высказываний относится не к Delphi, а к общим принципам ООП. В терминах ООП его высказывания кажутся мне весьма обоснованными. В отличии от высказываний его оппонентов.
← →
Канадец (2007-11-16 01:53) [382]Интерфейс, это контракт. Это обязательство объекта поддержать некую функциональность. Подписывать на это Object не правильно, т.к. 90% объектов не нуждаются в данном контракте и не готовы его имплементировать.
Конечно, несколько неудобно, что java.lang не содержит подобия .NET-кого IDisposable, но как по мне, то неудобством проблема и заканчивается. Если мы говорим о серьёзных разработах и серьёзном проектировании, то никто не мешает на уровне сore библиотек определить этот интерфейс и раз и на всегда забыть про эту проблему. Конечно, мир не идеален и в нём полно "китайских" разработчиков. Вполне возможно кому-нибудь придётся столкнуться с проблемой когда каждый "китаец" по-своему решает где ему релизить ресурсы. Ну а где гарантия, что эти "китайцы" будут для этого использовать IDisposable если он появится в java.lang? Где вообще гарантия, что подобные товарищи будут релизить ресурсы в деструкторах неуправляемых языков? Кто им помешает написать Close (Release, ReleaseAll, Clear and etc.) на Delphi или C++? Так что IHMO проблема всё-таки в головах, а не в языке.
P.S. Ни в коем случае не хотел обидить китайцев, большинство из них очень милые люди :)
← →
Черный Шаман (2007-11-16 02:04) [383]
> Юрий Зотов © (16.11.07 00:35) [378]
Дядя Юра это не поможет. В одном из моих первых проектов когда учился на своих ошибках, так как не у кого было особо спросить(остальные были еще хуже) я деструктор назвал в своих классахDestructor Free;
Вот так вот жестко. И TObject не спас :) А уровень армии китайских и индусских программистов примерно на том же уровне на котором я был 5 лет назад.
Так что не поможет... индусом много, а проектов мало и каждый индус чтит свою собственную камасутру.
← →
Piter © (2007-11-16 02:15) [384]Юрий Зотов © (15.11.07 21:22) [373]
Ты просто его не дочитал. Почитай, что он пишет об аварийном завершении (которое программист тоже должен предполагать).
в моем цитировании есть фраза:
"Код завершения процесса меняется созначения STILL_ACTIVE на код, переданный в ExitProcess или TerminateProcess"
Вы хотите сказать, что TerminateProcess - это не аварийное завершение? Я сколько не читал, Рихтер всегда говорил одно - система ДОЛЖНА уничтожать все захваченные ресурсы при завершении процесса, даже если сам процесс этого не сделал. И не только Рихтер это говорил.
Если не сложно - процитируйте тогда слова Рихтера об ином развитии событий.
← →
Piter © (2007-11-16 02:26) [385]Юрий Зотов, хотя вам конечно лень искать нужное место. Нет проблем, давайте просто поэкспериментируем.
Я взял одну из своих библиотек, обычная DLL, ничего особенного - плагин под Miranda. Берем приложение, код простейший:procedure TForm1.Button1Click(Sender: TObject);
begin
LoadLibrary("tz_test.dll") ;
end;
Жмакаю на кнопку, библиотека грузится, после чего пытаюсь удалить библиотеку из проводника. Получаю вот это:
http://sovserv.ru/dc/fileexchange/dll_test.gif
Заметьте! Нигде в программе нет FreeLibrary для этой библиотеки и быть не может, так как хэндл не сохраняется.
Я открываю диспетчер задач - снимаю процесс (это не аварийное завершение?!) - и ?!?!? И библиотека спокойно удаляется!
Теперь ваши слова, сказанные с гонором, с упреком:
"Кстати, ты в курсе, что если программа загрузила DLL, а потом не вызвала FreeLibrary, то эта DLL в текущей сессии системы уже не выгрузится никогда, даже после завершения всех юзающих ее программ? Потому что система будет считать ее используемой"
С каких пор дядя Юра система считает библиотеку используемой, но позволяет ее легко удалять?
Мне кажется я предоставляю аргументы.
Если вы сейчас не скажите никакой конкретики, а отмахнетсь только тем, что мол "ты ниечего не понимаешь, иди учи" - то я умою руки, разговаривать в таком ключе бесполезно.
← →
Piter © (2007-11-16 02:29) [386]весь этот простейший эксперимент можете скачать здесь:
http://sovserv.ru/dc/fileexchange/dll_test.zip (218 KB)
И убедиться самостоятельно.
← →
umbra © (2007-11-16 04:24) [387]2 Piter ©
если Вы еще не заметили, здесь речь идет не об операционных системах, а о структуре разных языков программирования.
← →
Юрий Зотов © (2007-11-16 05:37) [388]Миш, задолбал.
"W для П", 3-е издание, стр 47, 4-й абзац сверху. Читай на здоровье.
Это что касается выгрузки DLL. А что касается того, как ты тут неоднократно пытался заставить сборщик мусора еще и ресурсы чистить - ну, тут no comments.
И еще - тебе тут уже подтверждали, что на практике некоторые вещи выглядят не совсем так, как в книжках.
← →
Evgeny V © (2007-11-16 06:47) [389]
> DiamondShark © (15.11.07 12:10) [252]
В JAVA это декларативно не запрещено. Я могу например вызвать dspose() для JFrame из другого потока (в отличие от .NET, где явный вызов освобождения окна из другого потока вызовет Exception). Более того, поток в JAVA создавший объект класса JFrame в методе main программы не является GUI потоком, обрабатывающим события GUI интерфейса. Поток GUI интерфейса создается при первом вызове метода JFrame.show() или JFrame.SetVisible(true), после чего обычно поток main(первичный поток приложения) и завершает работу(если нет другого кода далее).
Другое дело, что при "работающем" окне не хорошо что-то, что требует синхронизации с потокм GUI, но если ссылки на ресурс обнулены и GC посчитает необходимым освободить ресурс, он его освободит.
Думаю и .NET можно было бы решить этот вопрос через Invoke, в нем окна действительно "принадлежат" создавшему их потоку.
← →
serger___ (2007-11-16 07:34) [390]
Можно привести пример логгера, который:
- открывает файл в своем конструкторе;
- имеет метод записи переданной строки;
- закрывает файл, когда становится не нужен.
public static java.util.logging.Logger log;
...
// Настройка логгирования
LogManager manager = LogManager.getLogManager();
Logger log = Logger.getLogger("log.txt");
FileHandler fh;
if (lim >=0)
fh = new FileHandler(System.getProperty("user.dir")+props.getProperty("logFile"), lim, 1, true);
fh.setEncoding("Cp1251");
log.addHandler(fh);
manager.addLogger(log);
...
log.log(Level.INFO,"Я тут!");
...
log.log(Level.INFO,"Или тут!");
...
Внутри:
Runtime
/**
* Registers a new virtual-machine shutdown hook.
*
* <p> The Java virtual machine shuts down in response to two kinds
* of events:
*
* <ul>
*
* <p> <li> The program exits normally, when the last non-daemon
* thread exits or when the <tt>{@link #exit exit}</tt> (equivalently,
* <tt>{@link System#exit(int) System.exit}</tt>) method is invoked, or
*
* <p> <li> The virtual machine is terminated in response to a
* user interrupt, such as typing <tt>^C</tt>, or a system-wide event,
* such as user logoff or system shutdown.
*
* </ul>
*
* <p> A shutdown hook is simply an initialized but unstarted
* thread. When the virtual machine begins its shutdown sequence it will
* start all registered shutdown hooks in some unspecified order and let
* them run concurrently. When all the hooks have finished it will then
* run all uninvoked finalizers if finalization-on-exit has been enabled.
* Finally, the virtual machine will halt. Note that daemon threads will
* continue to run during the shutdown sequence, as will non-daemon threads
* if shutdown was initiated by invoking the <tt>{@link #exit exit}</tt>
* method.
*
* <p> Once the shutdown sequence has begun it can be stopped only by
* invoking the <tt>{@link #halt halt}</tt> method, which forcibly
* terminates the virtual machine.
*
* <p> Once the shutdown sequence has begun it is impossible to register a
* new shutdown hook or de-register a previously-registered hook.
* Attempting either of these operations will cause an
* <tt>{@link IllegalStateException}</tt> to be thrown.
*
* <p> Shutdown hooks run at a delicate time in the life cycle of a virtual
* machine and should therefore be coded defensively. They should, in
* particular, be written to be thread-safe and to avoid deadlocks insofar
* as possible. They should also not rely blindly upon services that may
* have registered their own shutdown hooks and therefore may themselves in
* the process of shutting down.
*
* <p> Shutdown hooks should also finish their work quickly. When a
* program invokes <tt>{@link #exit exit}</tt> the expectation is
* that the virtual machine will promptly shut down and exit. When the
* virtual machine is terminated due to user logoff or system shutdown the
* underlying operating system may only allow a fixed amount of time in
* which to shut down and exit. It is therefore inadvisable to attempt any
* user interaction or to perform a long-running computation in a shutdown
* hook.
*
* <p> Uncaught exceptions are handled in shutdown hooks just as in any
* other thread, by invoking the <tt>{@link ThreadGroup#uncaughtException
* uncaughtException}</tt> method of the thread"s <tt>{@link
* ThreadGroup}</tt> object. The default implementation of this method
* prints the exception"s stack trace to <tt>{@link System#err}</tt> and
* terminates the thread; it does not cause the virtual machine to exit or
* halt.
*
* <p> In rare circumstances the virtual machine may abort, that is,
* stop running without shutting down cleanly. This occurs when the
* virtual machine is terminated externally, for example with the
* <tt>SIGKILL</tt> signal on Unix or the <tt>TerminateProcess</tt> call on
* Microsoft Windows. The virtual machine may also abort if a native method goes awry
* by, for example, corrupting internal data structures or attempting to
* access nonexistent memory. If the virtual machine aborts then no
* guarantee can be made about whether or not any shutdown hooks will be
* run. <p>
*
* @param hook
* An initialized but unstarted <tt>{@link Thread}</tt> object
*
* @throws IllegalArgumentException
* If the specified hook has already been registered,
* or if it can be determined that the hook is already running or
* has already been run
*
* @throws IllegalStateException
* If the virtual machine is already in the process
* of shutting down
*
* @throws SecurityException
* If a security manager is present and it denies
* <tt>{@link RuntimePermission}("shutdownHooks")</tt>
*
* @see #removeShutdownHook
* @see #halt(int)
* @see #exit(int)
* @since 1.3
*/
public void addShutdownHook(Thread hook) {
SecurityManager sm = System.getSecurityManager();
if (sm != null) {
sm.checkPermission(new RuntimePermission("shutdownHooks"));
}
Shutdown.add(hook);
}
← →
serger___ (2007-11-16 07:34) [391]LogManager() :
// This private class is used as a shutdown hook.
// It does a "reset" to close all open handlers.
private class Cleaner extends Thread {
public void run() {
// If the global handlers haven"t been initialized yet, we
// don"t want to initialize them just so we can close them!
synchronized (LogManager.this) {
// Note that death is imminent.
deathImminent = true;
initializedGlobalHandlers = true;
}
// Do a reset to close all active handlers.
reset();
}
}
/**
* Protected constructor. This is protected so that container applications
* (such as J2EE containers) can subclass the object. It is non-public as
* it is intended that there only be one LogManager object, whose value is
* retrieved by calling Logmanager.getLogManager.
*/
protected LogManager() {
// Add a shutdown hook to close the global handlers.
try {
Runtime.getRuntime().addShutdownHook(new Cleaner());
} catch (IllegalStateException e) {
// If the VM is already shutting down,
// We do not need to register shutdownHook.
}
}
/**
* Reset the logging configuration.
* <p>
* For all named loggers, the reset operation removes and closes
* all Handlers and (except for the root logger) sets the level
* to null. The root logger"s level is set to Level.INFO.
*
* @exception SecurityException if a security manager exists and if
* the caller does not have LoggingPermission("control").
*/
public void reset() throws SecurityException {
checkAccess();
synchronized (this) {
props = new Properties();
// Since we are doing a reset we no longer want to initialize
// the global handlers, if they haven"t been initialized yet.
initializedGlobalHandlers = true;
}
Enumeration enum_ = getLoggerNames();
while (enum_.hasMoreElements()) {
String name = (String)enum_.nextElement();
resetLogger(name);
}
}
← →
Юрий Зотов © (2007-11-16 08:09) [392]> serger___ (16.11.07 07:34) [390]
Вот именно. Простейшая, детская задачка потребовала выкрутасов на уровне хуков VM. Похоже, что-то не так в датском королевстве?
← →
Игорь Шевченко © (2007-11-16 09:40) [393]Сколько же можно сокрушаться по поводу несовершенства мира ? :)
← →
Romkin © (2007-11-16 10:34) [394]
> Сколько же можно сокрушаться по поводу несовершенства мира
> ? :)
А никто и не сокрушается. Зотова попросили объяснить, почему он чувствует, что java - это трехколесный велосипед.
Хотя код serger___ показывает, что скорее - это айсберг :)
← →
Игорь Шевченко © (2007-11-16 10:58) [395]Romkin © (16.11.07 10:34) [394]
О java лучше спрашивать тех, кто не отравлен ядом Delphi, не так ли ?
← →
@!!ex © (2007-11-16 11:10) [396]спор на самом деле ни о чем.
Дельфи не заменяет Явы, Ява Дельфи тоже не заменяет...
← →
Evgeny V © (2007-11-16 11:32) [397]
> Romkin © (16.11.07 10:34) [394]
Был показан исходный код библиотечного класса, намного превышающий запрошенную функциональность. Я не знаю JAVА достаточно хорошо, но сделать простой однопоточный логгер не проблема, если почитать документацию и использовать правильно например synchronized, то вполне можно использовать и как threadsafe класс.
Быстрое, без синхронизации для многопоточности, без проверок на корректность и проверки на компилируемость - нет JAVA под рукой (Из кода Зотова) - Здесь применено агрегирование, хотя можно было и сделать и с наследованием. Файл закрывается после записи в него строки
public class Loggger {
private FileOutputStream stream;
public Loggger(string FileName) {
string fileName;
try {
fileName=FileName;
}
catch (IOException e) {
e.printStackTrace();
}
}
public void writeString(String s) throws IOException {
stream = new FileOutputStream(fIleName,true);
stream.write((s + "\n").getBytes());
stream.Flush;
stream.close();
}
}
← →
Evgeny V © (2007-11-16 11:39) [398]Evgeny V © (16.11.07 11:32) [397]
немного исправил, ибо копи и пасте к дору как всегда не привели
public class Loggger {
private FileOutputStream stream;
potected string fileName;
public Loggger(string FileName) {
fileName=FileName;
}
public void writeString(String s) throws IOException {
try {
stream = new FileOutputStream(fIleName,true);
stream.write((s + "\n").getBytes());
} end try
finally
{
if (null!=stream)
{
stream.Flush;
stream.close();
}//end if
}end finally
catch (IOException e) {
e.printStackTrace();
}//end catch
}//end write string
}//end class
← →
Piter © (2007-11-16 14:02) [399]Юрий Зотов © (16.11.07 5:37) [388]
Миш, задолбал
Юрий, вам не надоело это повторять? Мы или разговариваем, или нет. Вы за последние 5 постов не сказали НИЧЕГО КОНКРЕТНОГО, хотя я пытаюсь приводить аргументы, реальные, цитаты, пишу ПРИМЕРЫ ПРОГРАММ. Так скажите сразу - мне мало лет и я ничего не понимаю, и успокойтесь, это в последнее время стандартная тактика.
Я вам написал, чтобы вы хоть что-то конкретное сказали. Вы опять НИ-ЧЕ-ГО не сказали? Где тот Зотов, который ВСЕГДА спорил аргументировано, даже с полными чайниками? Теперь офигевающий от своей крутости профессионал, с нисхождением смотряющий на всех и вся? Ну так честно слово - лучше ВООБЩЕ ничего тогда не писать.
Юрий Зотов © (16.11.07 5:37) [388]
"W для П", 3-е издание, стр 47, 4-й абзац сверху. Читай на здоровье
у меня четвертое издание, страница там о другом эта.
Юрий Зотов © (16.11.07 5:37) [388]
Это что касается выгрузки DLL
а что вы скажите про мой пример? Я вам написал РЕАЛЬНЫЙ пример, библиотека загрузилась - ее удалить нельзя, FreeLibrary не вызывалась, после завершения процесса DLL легко удалилась. Это что, просто так?
Почему вы легко игнорируете "неприятные" вам места? Может, вы это сами объяснить не можете? А зачем тогда на меня гнать, какой я лох?
Юрий Зотов © (16.11.07 5:37) [388]
И еще - тебе тут уже подтверждали, что на практике некоторые вещи выглядят не совсем так, как в книжках
естественно. Но повторюсь - вы с ГОНОРОМ утверждали, что коли я этого не знаю - что мне сюда лезть. А что я по сути не знал? Я не знал о каких-то ГЛЮКАХ WINDOWS. Очень хорошее средство загнобить человека дяд Юра, честное слово - браво! Упрекнуть человека в том, что он не знает о каком-то глюке windows (кстати, еще не доказанном вообще, никаких подтверждений от ВАС не поступало, в отличии от меня) и на самом деле этот глюк мог быть например на XP первой версии, а в SP2 все давно исправили. И на основании этого факта говорить, что я ничего не понимаю.
Следующим шагом будет гнобление по возрасту и вероиспеводению - я так понимаю? Нет слов, сори.
← →
uw © (2007-11-16 14:38) [400]Есть набор совершенно произвольных классов, о каждом из которых известно лишь то, что он имеет метод execute.
Кривобокие несколько классы - творить их нужно в два приема, а убивать хотим одним ударом :-) Иначе говоря, их сначала нужно сотворить, а потом сказать "ха", т.е. вдохнуть в них жизнь, чтобы они зашевелились. Акт творения и оживления, вообще-то, легко было делать в одном лишь конструкторе. Но уж если там, где легко, делаем в два шага, то почему же и на убиение не потратить ровно столько же!
Хотя, я согласен, кривость финализатора не украшает Яву :-)
← →
Piter © (2007-11-19 12:24) [401]дядя Юра, нашел специально для вас. Рихтер, четвертое издание, страница 79, цитирую:
"... система высвобождает все принадлежащие процессу ресурсы: возвращает себе выделенную им память, закрывает любые открытые файлы, уменьшает счетчики соответствующих объектов ядра и разрушает все его User- и GDI-объекты.
По завершении процесса (не важно каким способом) система гарантирует: после него ничего не останется - даже намеков нато, что он когда-то выполнялся. Завершенный процесс не оставляет за собой никаких следов. Надеюсь, я сказал ясно."
Выделено не мною!
Итак, с одной стороны источник - Рихтер, с другой - Юрий Зотов, мнения противоположны. Это уже повод задуматься. Но на высказывания ЮЗ я самолично написал тестовый пример и он опроверг его мнение (пример можно найти выше) и полностью подтверждает написанное Рихтером. Что же остается то?
А после этого Юрий меня убеждает в том, что я нихрена не понимаю и не стоит мне вмешиваться в дискуcсию. Ведь каждый школьник знает, что Рихтер - лжец.
Вот это и очень не нравится, убеждение в своей правоте ВОТ ТАКИМ ВОТ образом.
← →
Юрий Зотов © (2007-11-19 14:02) [402]Миша, прошла неделя. Сколько нужно времени, чтобы твое ущемленное самолюбие успокоилось?
1. Тебе в этой же ветке не раз говорили (и не только я), что теория и практика не всегда совпадают. И DLL может не освобождаться, и файлы почему-то лочатся, и ресурсов GDI вдруг перестает хватать, а уж завис коннекта к БД - так это завсегда пожалуйста.
2. В этой же ветке ты неоднократно путал сборку мусора и освобождение неуправляемых ресурсов - что однозначно говорит о непонимании сути вопроса. На что тебе и было указано (и тоже не только мною) - но ты с непонятным упорством и продолжал спорить неизвестно о чем, и продолжал путать зеленое со сладким.
3. Хочешь, чтобы я извинился? ОК, извини. Но прими, пожалуйста во внимание, что впредь, как только я увижу, что ты споришь о чем-либо, толком не понимая предмета (а за тобой такое водится), об этом будет сказано открыто и прямо.
И на этом я разговор заканчиваю.
← →
Mystic © (2007-11-19 16:03) [403]> ... система высвобождает все принадлежащие процессу ресурсы:
Ресурсы могут и не принадлежать процессу. Я могу открыть транзакцию на сервере БД, создать временный файл и т. п.
← →
Piter © (2007-11-19 19:39) [404]Юрий Зотов © (19.11.07 14:02) [402]
Тебе в этой же ветке не раз говорили (и не только я), что теория и практика не всегда совпадают. И DLL может не освобождаться, и файлы почему-то лочатся, и ресурсов GDI вдруг перестает хватать
и в этой же ветке я вас пять раз спрашивал и вы ни разу не ответили - неужели это именно то, что я должен знать, чтобы иметь смелость с вами спорить? Рихтер однозначно сказал:
"Завершенный процесс не оставляет за собой никаких следов. [b]Надеюсь, я сказал ясно[/b]."
Концовка фразы явно говорит о том, что вопрос злободневный, но ответ Рихтера - именно таков. И по-моему опыту именно так и бывает.
Да, бывает - программа загрузила DLL, поработала, выгрузилась - а DLL занята. А почему? А например потому, что программа зарегистрировала DLL в качествее shell расширения explorer"а. Ну тогда понятно - windows все очистила как надо, да только теперь explorer.exe загрузил эту библиотеку - понятное дело, что она занята. И я уверен, в подавляющем большинстве случае когда кажется что windows не произвела уборку мусора - это лишь кажется, а если разобраться - все объяснимо.
А если даже что-то осталось неосвобожденным, ну так это явно БАГ системы. И еще раз, вы говорили мне о том, что я не имею право с вами разговаривать потому, что я не знаю этого бага (естественно, недокументированного) windows. Прэлестно. Мне кажется это неправильным, вот и все о чем я говорю.
Вы сказали конкретную фразу - если загрузить библиотеку и не сделать freelibrary, а процесс завершится - библиотека будет занята в этом сеансе все равно. Я провел эксперимент, написал тестовое приложение - ваши слова НЕ подтвердились. Заметьте, я не утверждаю, что вы ничего не знаете и вам надо почитать книжки прежде чем со мной спорить. Но обидно, когда вы мне это говорите, что я ничего не знаю, доказывая это примерами, которые ОПРОВЕРГАЮТСЯ простейшими экспериментами и которые противоречат классическим авторам.
Юрий Зотов © (19.11.07 14:02) [402]
В этой же ветке ты неоднократно путал сборку мусора и освобождение неуправляемых ресурсов
я этого не путал. Вы меня попросили пояснить, что я представляю себе под "неуправляемыми ресурсами". Я вам рассказал. НИ слова комментария, подозреваю, что я все правильно сказал и подловить было негде.
← →
Piter © (2007-11-19 19:45) [405]Юрий Зотов © (19.11.07 14:02) [402]
как только я увижу, что ты споришь о чем-либо, толком не понимая предмета (а за тобой такое водится), об этом будет сказано открыто и прямо
это очень некультурно - говорить, что водится. Если мы будем спорить в стиле "кто водится за кем" - на каждого человека можно вылить ушат говна. На вас, Юрий, точно также, я вас уверяю. Поднимая все темы, личную переписку - я много что могу рассказать про вас. А вы наверняка про меня. Но вы каждый раз используете аргументы в этом стиле, я и прошу этого не делать.
Спорить надо аргументировано, я думаю вы с этим согласны. Или не спорить вовсе. Я вам приводил аргументы, в ответ я слышал "ты ничего не понимаешь" - это НЕ аргумент, даже если я не прав. Это ни о чем, это фраза в воздух, это давление авторитетом. Если я не прав - скажите в чем, если я неправильно составил тестовый пример - расскажите в чем ошибка. Вот я предлагаю только так.
В данной ветке в мой адрес вы вообще ни одного аргумента не сказали, только пытались задавить авторитетом. "а ты не вмешивайся", "а ты ничего не понимаешь", "миш хватит", "не смеши людей", но ни слова по делу.
Поэтому в следующий раз, если вы видите что я неправ, расскажите почему я не прав, если вы захотите сказать в стиле "Ты неправ хотя бы потому, что решил со мной поспорить" - то лучше промолчать и игнорировать посты. Ок?
← →
Johnmen © (2007-11-19 20:11) [406]Ты виноват уж тем, что хочется мне кушать (с)
← →
Anatoly Podgoretsky © (2007-11-19 20:11) [407]
> "Завершенный процесс не оставляет за собой никаких следов.
> [b]Надеюсь, я сказал ясно[/b]."
>
> Концовка фразы явно говорит о том, что вопрос злободневный,
> но ответ Рихтера - именно таков. И по-моему опыту именно
> так и бывает.
Что и глобальные атомы?
← →
Mystic © (2007-11-19 21:07) [408]> А если даже что-то осталось неосвобожденным, ну так это
> явно БАГ системы.
Поэтому Рихтер так и пишет, что все ресурсы освобождаются. В своих трудах он не заостряет внимание на БАГах,а рассказывает о том, какая была задумка e Microsoft. А задумка-то как раз и была освобождать все ресурсы процесса. И, возможно, что программисты Microsoft честно пытались. И в простейших случаях это работает. Тем не менее, иногда встречаются БАГи. И самый простой путь обойти эти баги это явно освободить то, что не освобождается. А если это войдет в привычку, то это и гарантия безопасности от будущих подобных багов.
Простой пример---не отпускается библиотека DLL. Собственно говоря тут есть два пути: либо стать тестером Microsoft и найти причину, по которой библиотека DLL не освободилась... Либо освободить ее руками и не мучаться. Какой путь ты выберешь?
← →
Virgo_Style © (2007-11-20 00:12) [409]Помню, как на одной изрядно замученной системе не освобождались mutex"ы...
← →
Piter © (2007-11-20 01:47) [410]Mystic © (19.11.07 21:07) [408]
я с тобой полностьтью согласен на 100%... но извини, ты наверное плохо читал.
← →
Германн © (2007-11-20 02:02) [411]
> Piter © (20.11.07 01:47) [410]
Ну тогда и меня сосчитай. Я тоже, имхо, плохо читал.
← →
Германн © (2007-11-20 02:41) [412]
> Virgo_Style © (20.11.07 00:12) [409]
>
> Помню, как на одной изрядно замученной системе не освобождались
> mutex"ы...
>
Вспоминая Германн © (15.11.07 17:58) [325]
могу добавить, что лично и не один раз был свидетелем ситуации, когда приложение завершалось, а СОМ-порт (который это приложение открывало) оказывался недоступен другим приложениям.
← →
Fktrc (2007-11-20 09:01) [413]> [29] Юрий Зотов © (13.11.07 23:02)
> > Kostafey © (13.11.07 22:36) [27]
>
> Вдобавок: отсутствие указателей и средств прямого управления
> памятью, автоматический подсчет ссылок и сборка мусора -
> все это, конечно, позволяет програмисту уделить большее
> внимание решению прикладной задачи и подстраховывает его
> от ошибок. Но, с другой стороны, лишает его мощных возможностей,
> предоставляемых хоть теми же указателями.
>
> Для программиста начинающего важнее первое (все равно пользоваться
> указателями он, как правило, толком не умеет). Для программиста
> опытного важнее второе (а ошибок управления памятью он уж
> как-нибудь и сам не допустит).
Напишите это оберонистам в Королевстве :)
← →
megabyte © (2007-11-20 12:16) [414]
> Всякий раз, когда говорю о том что программирую на Делфи,
> то почему-то у всех сразу становятся кислые рожи, как будто
> это язык лунатиков, почему?
Всякий раз, когда говорю, что програмирую на Дельфи, у всех глаза на лоб: "А что, на нем еще программируют..." %)
Топикстартеру: Дай преподу почитать статейку, мож какие мысли появятся Опасности обучения на Java
http://local.joelonsoftware.com/mediawiki/index.php/%D0%9E%D0%BF%D0%B0%D1%81%D0%BD%D0%BE%D1%81%D1%82%D0%B8_%D0%BE%D0%B1%D1%83%D1%87%D0%B5%D0%BD%D0%B8%D1%8F_%D0%BD%D0%B0_Java
← →
Romkin © (2007-11-20 13:19) [415]megabyte © (20.11.07 12:16) [414] Ох. Не надо о грустном :)
Связные списки... Хотя бы связные списки! К счастью, есть еще нормальные лабораторные :)
← →
Romkin © (2007-11-20 13:20) [416]Кстати, а как на java реализуется что-то вроде http://www.delphimaster.ru/articles/dsort/index.html
Страницы: 1 2 3 4 5 6 7 8 9
10 11 вся ветка
Форум: "Прочее";
Текущий архив: 2007.12.16;
Скачать: [xml.tar.bz2];
Память: 1.97 MB
Время: 0.061 c
