Здравствуйте, AndrewVK, Вы писали:
VD>>А ну, ну. Вот только их применяют еще и, чтобы от обратной связи уйти.
AVK>Кто применяет?
Да все кто сталкивается с циклическими ссылками подвешенными на глобальные переменные. Самое простое завести вик ссылку вместо обычной. Когда основная ссылка отвалится, то и проблема исчезнет.
... << RSDN@Home 1.1.4 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
AVK>>Кто применяет?
VD>Да все кто сталкивается с циклическими ссылками подвешенными на глобальные переменные.
Все это значит никто.
VD> Самое простое завести вик ссылку вместо обычной. Когда основная ссылка отвалится, то и проблема исчезнет.
Она исчезнет если выполнение события в фантомах не критично. А если критично то проблема остается. Вобще — вызов события у фантомов, даже если это временное явление это кривизна. Как минимум нужно вводить в подписчика признак фантомного состояния и не отрабатывать в этом состоянии событие, что в итоге ничуть не проще чем нормальная ручная отписка ненужных экземпляров от статического события.
Здравствуйте, AndrewVK, Вы писали:
VD>>Да все кто сталкивается с циклическими ссылками подвешенными на глобальные переменные.
AVK>Все это значит никто.
Фигово у тебя с теримнами.
VD>> Самое простое завести вик ссылку вместо обычной. Когда основная ссылка отвалится, то и проблема исчезнет.
AVK>Она исчезнет если выполнение события в фантомах не критично.
Да события тут могут быть даже не причем. Это общее решение. К тому же никаких фантомов тут нет. До сборки мусора объект есть и доступен по вику, после ссылки уже пусты.
AVK> А если критично то проблема остается. Вобще — вызов события у фантомов, даже если это временное явление это кривизна. Как минимум нужно вводить в подписчика признак фантомного состояния и не отрабатывать в этом состоянии событие, что в итоге ничуть не проще чем нормальная ручная отписка ненужных экземпляров от статического события.
Да лишнее все это. Мне кажется ты начинаешь выдумывать проблему.
... << RSDN@Home 1.1.4 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Да события тут могут быть даже не причем. Это общее решение. К тому же никаких фантомов тут нет. До сборки мусора объект есть и доступен по вику, после ссылки уже пусты.
Он может и доступен, но уже никому не нужен и отрабатывать событие не должен, а он будет отрабатывать пока не запустится GC. Вобщем в данной конкретном случае слабые ссылки половинчатое решение.
Здравствуйте, S.Yu.Gubanov, Вы писали:
SYG>[OffTopic] SYG>Ну, блин, прямо рабовладельческий строй. Даешь демократию! SYG>[/OffTopic]
Как!? Вы не верите в американскую демократию?
Тогда мы летим к вам!
... << RSDN@Home 1.1.3 beta 1 >>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, AndrewVK, Вы писали:
AVK>Он может и доступен, но уже никому не нужен и отрабатывать событие не должен, а он будет отрабатывать пока не запустится GC. Вобщем в данной конкретном случае слабые ссылки половинчатое решение.
Ну, должен не должен — это все завист от задачи. Во многих случаях проблем не будет. Хотя несомненно можно создать ситуацию когда это будет приводить к проблемам.
... << RSDN@Home 1.1.4 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, S.Yu.Gubanov, Вы писали:
SYG>Здравствуйте, Sergey J. A., Вы писали:
SJA>>Здравствуйте, S.Yu.Gubanov, Вы писали:
Ael>>>>Подскажите, пожалуйста ссылку на ветку в rsdn.ru, где мы наиболее мастерски объяснялись сильные стороны неуправляемого С++ по сравнению с платформами .NET Framework или Java — интересно почититать.
Ael>>>>Спасибо!
SYG>>>А противоположную по смыслу ссылку не желаете?
SJA>>Давай. Кто-нибудь да пожелает. Я например....
SYG>А далеко ходить и не надо, вон прямо в соседней ветке... SYG>Короче, .NET Framework или Java отличаются от обычного С++ тем, что там есть сборщик мусора. А сборщик мусора является необходимым условием для написания модульных программ. На обычном С++ модульные программы писать невозможно.
Cборщик мусора предназначен только для того, чтобы система работала корректно несмотря на кривые программы, которые под ней запускаются. Но никак не отменяет правила — любой модуль, программа, просто кусок кода должен контролировать все ресурсы, которые он использует и отвечать за их своевременный возврат системе.
И его наличие ни разу не является поводом писать НЕКОРРЕКТНЫЙ код.
Вам приходилось наблюдать, как незакрытый RecordSet делает Web-приложение совершенно нерабочим при серьезной нагрузке, и при этом Memory Leak-и происходят не в Java Application Server-е а в процессе сервера БД?
Или как парсер текста, активно использующий java.lang.String останавливается на десятки секунд?
Нечто подобное лет 8 назад уже проходилось слышать от "старых unix-оидов", которые использовали свои подходы к написанию мелких утилит при серверных серверных или просто интерактивных приложений и в итоге создавали немало проблем и бессонных ночей своим коллегам по комманде.
Лично для меня Java, VB,.Net и т.д. это просто RAD-ы, которые существенно ускоряют и упрощают разработку, но попытки на уровне технодогии/языка исправлять ошибки разработчика — это их ОГРОМНЫЙ недостаток.
Здравствуйте, Kluev, Вы писали:
K>Думаю пока рано делать выводы. Все "тяжелые" программы (САПРЫ, оффисы и т.п.) которые мы юзаем пока в unmanaged коде.
Здравствуйте, remission, Вы писали:
R>Cборщик мусора предназначен только для того, чтобы система работала корректно несмотря на кривые программы, которые под ней запускаются. Но никак не отменяет правила — любой модуль, программа, просто кусок кода должен контролировать все ресурсы, которые он использует и отвечать за их своевременный возврат системе. R>И его наличие ни разу не является поводом писать НЕКОРРЕКТНЫЙ код.
Фишка в том что некорректный для систем без GC код становится корректным. "Память больше не ресурс", (С) IT. И это дает возможность строить более гибкие и сложнрые системы. Например нет никакой необходимости заботится о том кто грохнет выделенный тобой блок памяти, соотв. всякие ReleaseBuffer etc. уходят в небытие.
R>Вам приходилось наблюдать, как незакрытый RecordSet делает Web-приложение совершенно нерабочим при серьезной нагрузке, и при этом Memory Leak-и происходят не в Java Application Server-е а в процессе сервера БД?
Не надо путать управляемые ресурсы, с которыми GC работает, и неуправляемые.
R>Или как парсер текста, активно использующий java.lang.String останавливается на десятки секунд?
А вот парсер R#, использующий System.String не останавливается.
R>Лично для меня Java, VB,.Net и т.д. это просто RAD-ы, которые существенно ускоряют и упрощают разработку, но попытки на уровне технодогии/языка исправлять ошибки разработчика — это их ОГРОМНЫЙ недостаток.
GC это не попытки устранять ошибки разработчика, это паттерн такой управления памятью.
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, remission, Вы писали:
R>>Cборщик мусора предназначен только для того, чтобы система работала корректно несмотря на кривые программы, которые под ней запускаются. Но никак не отменяет правила — любой модуль, программа, просто кусок кода должен контролировать все ресурсы, которые он использует и отвечать за их своевременный возврат системе. R>>И его наличие ни разу не является поводом писать НЕКОРРЕКТНЫЙ код.
AVK>Фишка в том что некорректный для систем без GC код становится корректным. "Память больше не ресурс", (С) IT. И это дает возможность строить более гибкие и сложнрые системы. Например нет никакой необходимости заботится о том кто грохнет выделенный тобой блок памяти, соотв. всякие ReleaseBuffer etc. уходят в небытие.
ОК, переформулируем — если речь идет об ООП то программа должна явно управлять циклом жизни (lifecycle) любого обьекта который она создала и в нужный момент явно его удалить.
GC во первых — просто развращает, во вторых делает вообще невозможным поиск Memory leak-ов путем автоматическог анализа кода и очень сильно затрудняет их поиск путем Code Review.
R>>Вам приходилось наблюдать, как незакрытый RecordSet делает Web-приложение совершенно нерабочим при серьезной нагрузке, и при этом Memory Leak-и происходят не в Java Application Server-е а в процессе сервера БД? AVK>Не надо путать управляемые ресурсы, с которыми GC работает, и неуправляемые.
Наличие такого инструмента как GC как-раз провоцирует некоторых(многих) на то, чтобы передать управление всеми ресурсами GC (все-равно ведь (например в Java) разработчики стандартных компонент позаботились о том чтобы в finalize() освободить в т.ч. и внешние ресурсы, с которыми GC не работает).
Способность отличать "управляемые ресурсы, с которыми GC работает, и неуправляемые" требует от разработчика гораздо более высокого уровня/опыта, чем просто управлять всеми ресурсами.
Более того, не всегда есть возможность знать заранее в каком случае "Память больше не ресурс", а когда обьект/некоторые его части были созданы на внешнем сервере, и позволить GC решать, когда он будет освобожден это непозволительная роскошь.
Даже когда разработчик исползует jdbc, он вполне может не знать, будет ли незакрытый RecordSet просто Memory leak-ом на 20kb в java машите, который исправит GC, или незакрытым курсором в БД, который "весит" десятки мегабайт.
R>>Или как парсер текста, активно использующий java.lang.String останавливается на десятки секунд? AVK>А вот парсер R#, использующий System.String не останавливается.
Могу только порадоваться за эффективную реализацию GC в .Net, но в jdk 1.2.2 и 1.3 это была большая проблемма.
R>>Лично для меня Java, VB,.Net и т.д. это просто RAD-ы, которые существенно ускоряют и упрощают разработку, но попытки на уровне технодогии/языка исправлять ошибки разработчика — это их ОГРОМНЫЙ недостаток.
AVK>GC это не попытки устранять ошибки разработчика, это паттерн такой управления памятью.
Когда разработчик создает/использует smart-pointer-ы или пишет собственный Memory Manager, и отлично осознает как происходит управление используемыми ресурсами, то полностью согласен, "это паттерн такой управления памятью", но когда такая возможность предоставляется самой технологией, и создается иллюзия, что освобождаь ресурсы не надо вообще, то это недостаток технологии.
Например в Java я предпочел бы возможность решать в каждом отдельном случае делать "delete a" или "System.manageLifeTime(a)".
Пратика показывает, что C/C++ девелоперы достаточно быстро переквалифицируются в Java или C# и начинают эффективно работать, а в обратных случаях часто возникают большие проблеммы.
VD>>>Сколько бы я такого на КОМ-е за тоже время словил бы? D>>Надо было больше практиковаться.
VD>Куда же больше? Ты вон погляди сколько я статей по КОМ-у зафигачил...
ха! это ну совсем ни о чем не говорит. "Бумажный тигр" называется
Здравствуйте, Ael, Вы писали:
Ael>Подскажите, пожалуйста ссылку на ветку в rsdn.ru, где мы наиболее мастерски объяснялись сильные стороны неуправляемого С++ по сравнению с платформами .NET Framework или Java — интересно почититать.
Ты немного не "с той стороны" смотришь. C++ — язык. .Net или Java — среды со своими языками. Их сравнивать вообще нельзя. И нельзя будет впредь. Разве что так: C++ — трудный, а Java с библиотеками или .Net — сложные, но в принципе — нетрудные вещи.
Если тебе нужно определить — стоит ли изучать C++, то по крайней мере мой ответ — положительный. После него станет ясно — откуда у чего ноги растут в "современных" системах программирования. Кроме того, если научишься хорошо проектировать на C++, то будет проще и в других системах, в т.ч. — Java и .Net.
Ael>Спасибо!
Да пожалуйста.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, work69, Вы писали:
VD>>Куда же больше? Ты вон погляди сколько я статей по КОМ-у зафигачил...
W>ха! это ну совсем ни о чем не говорит. "Бумажный тигр" называется
Это называется трепач находка для шпионов. Попробуй сделайть хоть десяту долю того...
... << RSDN@Home 1.1.4 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, remission, Вы писали:
R>>>Или как парсер текста, активно использующий java.lang.String останавливается на десятки секунд? AVK>>А вот парсер R#, использующий System.String не останавливается.
R>Могу только порадоваться за эффективную реализацию GC в .Net, но в jdk 1.2.2 и 1.3 это была большая проблемма.
1. Ты тут вроде не на конкретную реализацию ЖЦ бочку катишь. А раз так, то что уж теперь стрелки переводить.
2. Я не раз делал тесты и могу уверенно сказать, что как раз ЖЦ в Яве как минимум не менее эффективен чем в дотнете. Так что это голословные обвинения. А "подвисать" что-то может просто из-за неверно выбранного олгоритма или класса.
R>Когда разработчик создает/использует smart-pointer-ы или пишет собственный Memory Manager, и отлично осознает как происходит управление используемыми ресурсами, то полностью согласен, "это паттерн такой управления памятью", но когда такая возможность предоставляется самой технологией, и создается иллюзия, что освобождаь ресурсы не надо вообще, то это недостаток технологии.
Кончай выдумывать. Сядь попрограммируй на дотнете или яве месяца два-три и я тубя уверяю, что подоную фигню у тебя язык не повернется говорить.
Реалии жизни выглядят совсем иначе. Следить за памятью в приложении просто не нужно. Остается ледить за анменеджед-ресурсами. Чтобы этого не делать выбирается тактика минимального захвата рисурса. Ресурс захаватывается только на время работы функции, а по выходу освобождается. Для автоматизации освобождения используется using. Итого в программе очень редко приходится вообще вспоминать о ресурсах. Ты просто пишешь код, и он работает.
R>Пратика показывает, что C/C++ девелоперы достаточно быстро переквалифицируются в Java или C# и начинают эффективно работать, а в обратных случаях часто возникают большие проблеммы.
И какой вывод ты делашь? Я бы сделал вывод, что Ява и Шарп более простые и логичные языки.
... << RSDN@Home 1.1.4 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, remission, Вы писали:
R>ОК, переформулируем — если речь идет об ООП то программа должна явно управлять циклом жизни (lifecycle) любого обьекта который она создала и в нужный момент явно его удалить.
Кто сказал? Ничего подобного. Программа должна управлять жизненным циклом объекта только в том случае если он нам интересен.
R>GC во первых — просто развращает,
Ты пробовал что так говоришь?
R> во вторых делает вообще невозможным поиск Memory leak-ов путем автоматическог анализа кода и очень сильно затрудняет их поиск путем Code Review.
. Мне понравилось — главный недостаток GC это мемори лики. Вобщем на самом деле для того чтобы сделать лик надо постараться. А уж если умудрился то никакой автоматический анализ кода тебя уже не спасет, поскорльку лики в условияхъ GC по формальным признакам ничем не отличимы от нормального кода и лики там на чисто логическом уровне.
AVK>>Не надо путать управляемые ресурсы, с которыми GC работает, и неуправляемые.
R>Наличие такого инструмента как GC как-раз провоцирует некоторых(многих) на то, чтобы передать управление всеми ресурсами GC
Не знаю кого оно там провоцирует, но боротся с незакрытием ресурсов путем увеличения нагрузки на программера очень странная идея.
R> (все-равно ведь (например в Java) разработчики стандартных компонент позаботились о том чтобы в finalize() освободить в т.ч. и внешние ресурсы, с которыми GC не работает).
finalize это уже для того чтобы аварии не вышло и применяют его довольно редко. Когда же хотят сделать освобождене неуправляемых ресурсов автоматическим используют отнюдь не finalize.
R>Способность отличать "управляемые ресурсы, с которыми GC работает, и неуправляемые" требует от разработчика гораздо более высокого уровня/опыта, чем просто управлять всеми ресурсами.
Практика показывает что это не так.
R>Более того, не всегда есть возможность знать заранее в каком случае "Память больше не ресурс", а когда обьект/некоторые его части были созданы на внешнем сервере,
Тогда это неуправляемый ресурс.
R>Даже когда разработчик исползует jdbc, он вполне может не знать, будет ли незакрытый RecordSet просто Memory leak-ом на 20kb в java машите, который исправит GC, или незакрытым курсором в БД, который "весит" десятки мегабайт.
Это тоже неуправляемый ресурс. И если разработчик не знает что коннекшен к базе неуправляемый то ему уже ничто не поможет.
R>>>Или как парсер текста, активно использующий java.lang.String останавливается на десятки секунд? AVK>>А вот парсер R#, использующий System.String не останавливается.
R>Могу только порадоваться за эффективную реализацию GC в .Net, но в jdk 1.2.2 и 1.3 это была большая проблемма.
Так получается что проблема не в GC, а в конкретной реализации?
AVK>>GC это не попытки устранять ошибки разработчика, это паттерн такой управления памятью.
R>Когда разработчик создает/использует smart-pointer-ы или пишет собственный Memory Manager, и отлично осознает как происходит управление используемыми ресурсами, то полностью согласен, "это паттерн такой управления памятью",
GC просто выполняет больше работы.
R> но когда такая возможность предоставляется самой технологией,
Интересно, это как? Возможность либо есть, либо ее нету.
R>и создается иллюзия, что освобождаь ресурсы не надо вообще, то это недостаток технологии.
Никаких иллюзий не создается. Памятью управлять не надо на самом деле, неуправляемыми ресурсами управлять необходимо. Где здесь ты иллюзию увидел?
R>Например в Java я предпочел бы возможность решать в каждом отдельном случае делать "delete a" или "System.manageLifeTime(a)".
Слава богу что разработчики и джавы и дотнета думают иначе.
R>Пратика показывает, что C/C++ девелоперы достаточно быстро переквалифицируются в Java или C# и начинают эффективно работать,
Достаточно поглядеть дотнетный форум и увидеть как народ упорно пытается слепо копировать решения с плюсов или дельфи, и сколько сил нужно потратить чтобы втолковать что так делать не следует, что становится понятным что не все так просто.
Что же касается кодирования, то да, порог вхождения в технологию очень низок, причем плюсовость входящего никакой рояли не играет, быстро начинать получается у всех.
R> а в обратных случаях часто возникают большие проблеммы.
Классно у тебя получается — технологию А осваивать быстро и просто, технологию Б сложно. Отсюда вывод — технология А отстой.
Здравствуйте, remission, Вы писали:
R>Наличие такого инструмента как GC как-раз провоцирует некоторых(многих) на то, чтобы передать управление всеми ресурсами GC (все-равно ведь (например в Java) разработчики стандартных компонент позаботились о том чтобы в finalize() освободить в т.ч. и внешние ресурсы, с которыми GC не работает). R>Способность отличать "управляемые ресурсы, с которыми GC работает, и неуправляемые" требует от разработчика гораздо более высокого уровня/опыта, чем просто управлять всеми ресурсами.
В полноценных современных ОО ОСях с интегрированным сборщиком мусора проблем с неуправляемостью нет. Проблемы возникают только когда Вы пытаетесь на языке со сборщиком мусора работать поверх древней неуправляемой ОСи: http://www.rsdn.ru/Forum/Message.aspx?mid=745571&only=1
Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>Кроме того, если научишься хорошо проектировать на C++, то будет проще и в других системах, в т.ч. — Java и .Net.
Боюсь что это не так, а наоборот. Проектирование для системы имеющей сборщик мусора отличается от проектирования для системы ее не имеющей. Программист, как минимум, испытывает шок при переходе к системам с GC. Надо очищать-освобождать свой разум от старых стереотипов ручного контроля памяти.
Лично я, например, был шокирован, когда осознал, что, скажем, в системах с GC широко применяется функция возвращающая список динамически созданных ею же самой объектов:
Obj = POINTER TO RECORD
Next: Obj;
(* ... *)END;
причем функция возвращает такой список ни капельки не заботясь о том кто потом будет освобождать выделенную память, и так повсюду...
демонстрирующее процесс мышления в рамках неуправляемого С++. А "Абстрактный агрегат" — мышление за рамками неуправляемого С++, по Вашему: "кривой взгляд на мир".
Здравствуйте, S.Yu.Gubanov, Вы писали:
ГВ>>Кроме того, если научишься хорошо проектировать на C++, то будет проще и в других системах, в т.ч. — Java и .Net.
SYG>Боюсь что это не так, а наоборот. Проектирование для системы имеющей сборщик мусора отличается от проектирования для системы ее не имеющей. Программист, как минимум, испытывает шок при переходе к системам с GC.
Да, испытывает. Например, из-за того, что в finally-блоке нужно прописывать всё то, что можно не писать на языке с детерминированным уничтожением объектов. Отсюда система на Java может оказаться раз 5 больше по объёму, чем аналог на C++.
SYG>Надо очищать-освобождать свой разум от старых стереотипов ручного контроля памяти.
Сдаётся мне, что не всё так просто. ИМХО, нужно освобождать свой разум от заблуждений, что что-то может быть в компьютере "бесплатно". А ещё от того, что компьютер представляет собой систему с бесконечной памятью и бесконечными дисками. Это называется самообманом.
SYG>Лично я, например, был шокирован, когда осознал, что, скажем, в системах с GC широко применяется функция возвращающая список динамически созданных ею же самой объектов: SYG>
SYG>Obj = POINTER TO RECORD
SYG> Next: Obj;
SYG> (* ... *)
SYG> END;
SYG>
SYG>причем функция возвращает такой список ни капельки не заботясь о том кто потом будет освобождать выделенную память, и так повсюду...
Что-то я не совсем понимаю. А в чём проблема реализовать согласованный контроль жизненного цикла для систем без GC?
SYG>Или вот другой пример, собственно, Вы Геннадий сами же написали критическое сообщение по поводу "Абстрактного Агрегата": SYG>http://www.rsdn.ru/Forum/Message.aspx?mid=744961&only=1
SYG>демонстрирующее процесс мышления в рамках неуправляемого С++. А "Абстрактный агрегат" — мышление за рамками неуправляемого С++, по Вашему: "кривой взгляд на мир".
Там приведена довольно подробная аргументация по этом поводу. И сказано, кстати, что к GC она не имеет никакого отношения.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
и в итоге создавали немало проблем и бессонных ночей своим коллегам по комманде.
