Здравствуйте, GlebZ, Вы писали:
GZ>Здравствуйте, Kluev, Вы писали:
K>>Ты все не понял. Ситуация состоит в том, что в процессе программирования алгоритмических ошибок не избежать. GZ>Не избежать. Но их меньше чем элементарных ошибок, и они чаще сразу тестируются при разработке. K>>В С++: K>>Я удалю обьект делитом (физически), а когда программа пойдет по невалидной ссылке то как правило будет runtime error. В деббагере это место сразу локализуется и дальше можно определить причину, почему осталась невалидная ссылка и исправить алгоритм. GZ>Как правило? О, нет. Это адская ошибка. Обычно она появляется не в лишней ссылке, а в лишнем(преждевременном) делете. Пока это пространство под убитым объектом никто не заполнил, ее можно считать живой и работающей и никто этого не замечает. GZ>С уважением, Gleb.
Ну так в C# еще хуже. В С++ это рано или поздно всплывет с грохотом. В шарпе все будет долго и упорно работать, только неправильно.
). E>Но только, если ошибка есть, то она обязательно проявится.
Нет. В том-то и дело-нет. В этом как раз и вся соль. Я согласен чтобы у меня были утечки памяти. Я вполне понимаю как они проявляются и что нужно делать. Они заметны. В этом же случае все более похабно чем может быть. Несколько раз встречал такие ошибки, хуже их не найдешь.
E>А вот со сборщиком мусора -- может вообще не проявиться.
С одной стороны — может и не проявиться. Просто памяти достаточно и никто не замечает что она увеличивается. Нехорошо и да ладно. С другой стороны, если у тебя память хорошо утекает, то будь ты в С++, или с GC в C# у тебя есть показания для профайлера.
Здравствуйте, Kluev, Вы писали:
K>Ну так в C# еще хуже. В С++ это рано или поздно всплывет с грохотом. В шарпе все будет долго и упорно работать, только неправильно. Re[17]: Смотрел на Java код. ...много думал.
).
> E> Но только, если ошибка есть, то она обязательно проявится.
> Нет. В том-то и дело-нет. В этом как раз и вся соль. Я согласен чтобы у меня были утечки памяти. Я вполне понимаю как они проявляются и что нужно делать. Они заметны. В этом же случае все более похабно чем может быть.
Ты говоришь совершенно о другой проблеме. Утечки памяти здесь ни при чем совершенно. Речь идет о том, что где-то осталась ссылка на старый объект, в то время как в других местах уже используется новый. Это логическая ошибка, которую порой очень тяжело отследить. В случае, если старый объект был бы удален, шансы на ее обнаружение были бы существенно выше, т.к. в тех местах, где он бы продолжал использоваться программа с хорошей вероятностью "падала".
Posted via RSDN NNTP Server 2.0 beta
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
Здравствуйте, Павел Кузнецов, Вы писали:
ПК>Ты говоришь совершенно о другой проблеме. Утечки памяти здесь ни при чем совершенно.
Конечно нет. Я упомянул про утечки поскольку они обычно используются как аргумент в managed vs unmanaged. ПК>Речь идет о том, что где-то осталась ссылка на старый объект, в то время как в других местах уже используется новый. Это логическая ошибка, которую порой очень тяжело отследить.
Дело в том, что я делал достаточно сложные структуры со множественными связями и на Net и на C# и на Паскале. И знаешь, я не помню таких ошибок. К алгоритмам и структурам как то всегда более акуратно подходишь. Их всегда не грех продумать конкретно. А вот ошибки по невнимательности на каждом шагу.
В Net существуют некоторые возможности для утечки иногда проскакивают. Но это ошибки данного плана. В основном это когда объект подписывают к какому-то событию время жизни которого достаточно большое, и забывают отписываться. Мне одного раза хватило, и я стал более акуратно относиться к отписке от событий. В остальном, о том чтобы обнулять ссылки я давно уже не задумываюсь. Если подобного не вписано в некоторый алгоритм. ПК>В случае, если старый объект был бы удален, шансы на ее обнаружение были бы существенно выше, т.к. в тех местах, где он бы продолжал использоваться программа с хорошей вероятностью "падала".
Что такое хорошая вероятность? В какой момент она создается?
Че-то я вас не пойму, господа. Вы никогда не встречали в С++ Access Violation который появлялся ниоткуда после перекомпиляции? Или Unit Test которые работают правильно 9 раз из 10? Не верю....
GZ>Что такое хорошая вероятность? В какой момент она создается? GZ>Че-то я вас не пойму, господа. Вы никогда не встречали в С++ Access Violation который появлялся ниоткуда после перекомпиляции? Или Unit Test которые работают правильно 9 раз из 10? Не верю....
Хорошая или плохая, но без GС она есть.
Если у вас программа 9 из 10 раз работает без Access Violation, то она эти 9 раз работет неверно — адрессуется не к тому объекту и вы этого не замечаете.
C GC она все десять раз сработает без ошибок и все десеть неверно, теперь ошибку сложнее обнаружить и кроме того сразу нет ясности из-за чего она: причин для неправильной работы море и неправильный указатель лишь одна из них.(Access Violation — прямо указывает на необходимость проверить указатели, и нередко сразу указывает на не исправленную ссылку)
ИМХО. GC нужен. Но и комманда delete, лишней не будет. Если бы можно было бы для объектов принудительно задавать delete, и если бы GC находил ещё ссылки на этот объект и тогда выдовал exception — это бы было идельно.
ЗЫ: Я тебя породил, я тебя и убью! — такое часто нужно, и иметь хоть какую-нибудь возможность конролировать процесс это не так уж и плохо.
Здравствуйте, n0name2, Вы писали:
N>Здравствуйте, vladserge, Вы писали:
V>>Вы б поискали по форуму про MS VM как она попрежнему всех делает...
N>нюню... кого она делает? это вы про отрисовку строк чтоли? кроме как быстро рисовать MS VM ниче не может, вообще ничего. если надо че-то быстро отрисовывать на Java5 юзайте SWT и будет вам щастье.
N>в любом коректном микробенчмарке не юзающем GDI MS VM сольет по полной.
N>вообще судя по всему вы явой интересуетесь раз в полгода а не юзаете ее сервер сайдный вариант каждый день.
"микробенчмарк" это такой бенчмарк который в общем и целом плохой поэтому мы переходим к замерам
частных ситуаций? Я правильно понял?
Здравствуйте, astranom, Вы писали:
A>Хорошая или плохая, но без GС она есть. A>Если у вас программа 9 из 10 раз работает без Access Violation, то она эти 9 раз работет неверно — адрессуется не к тому объекту и вы этого не замечаете.
+1 Только небольшая поправка. К области памяти которая может еще содержать данные от убитого объекта.
A>C GC она все десять раз сработает без ошибок и все десеть неверно, теперь ошибку сложнее обнаружить и кроме того сразу нет ясности из-за чего она: причин для неправильной работы море и неправильный указатель лишь одна из них.(Access Violation — прямо указывает на необходимость проверить указатели, и нередко сразу указывает на не исправленную ссылку)
Почему нет ясности? У тебя есть гарантия что они будут работать либо верно, либо неверно. Если неверно, то ищи ошибку.
A>ИМХО. GC нужен. Но и комманда delete, лишней не будет. Если бы можно было бы для объектов принудительно задавать delete, и если бы GC находил ещё ссылки на этот объект и тогда выдовал exception — это бы было идельно.
Есть стандартная фича. Если у объекта прошел Dispose(аналог детерменированного деструктора) то на все методы которые не могут быть вызваны ты можешь бросать ObjectDisposedException. Это более локализуемое чем Access Violation, который к тому-же имеет тенденцию вызываться в nt.dll.
A>ЗЫ: Я тебя породил, я тебя и убью! — такое часто нужно, и иметь хоть какую-нибудь возможность конролировать процесс это не так уж и плохо.
Не нужно. Практически никогда не нужно. Это С++ в деструкторе нужно удалить все зависимые объекты. С GC все зависимые объекты становятся мертвыми автоматически. После одного-двух больших проектов начинаешь понимать что деструкторы без unmanaged ресурсов практически не нужны. Без них спокойно и нормально живется и о них не нужно задумываться.
То что описывал Kluev штука весьма специфичная. Практически всегда сетевые структуры можно выразить в виде деревьев. В этом случае, если у тебя при стирании ссылки теряется вся ветка. Чаще такие структуры отображаются вручную через массивы чтобы не лазить на тормозное выделение памяти. А там уже другие законы. Насколько я понял и у него кастомный менеджер памяти.
Здравствуйте, c-smile, Вы писали:
N>>в любом коректном микробенчмарке не юзающем GDI MS VM сольет по полной.
CS>"микробенчмарк" это такой бенчмарк который в общем и целом плохой поэтому мы переходим к замерам CS>частных ситуаций? Я правильно понял?
ну народу (см. скажем топик про "сравнение про-ти Java 1.5 и .NET 2.0" в священных войнах) как правило лень качать/запускать/анализировать нормальные бенчмарки JVM, скажем, SPECjbb2000. так что лобают что в голову взбредет, то сортировку пузырьком, то аллокацию объектов, то перемножение матриц.
в общем, в "микробенчмарках" нет ничего плохого т.к. они более понятны народу и как следствие им больше доверяют. но от MSVM на сервере постарайтесь избавится ASAP...
Здравствуйте, Павел Кузнецов, Вы писали:
ПК>Ты говоришь совершенно о другой проблеме. Утечки памяти здесь ни при чем совершенно. Речь идет о том, что где-то осталась ссылка на старый объект, в то время как в других местах уже используется новый. Это логическая ошибка, которую порой очень тяжело отследить. В случае, если старый объект был бы удален, шансы на ее обнаружение были бы существенно выше, т.к. в тех местах, где он бы продолжал использоваться программа с хорошей вероятностью "падала".
можно пример (на неком псевдокоде) того что вы имеете в виду? никак немогу понять как то о чем вы говорите может быть возможным.
О, нет. Это адская ошибка. Обычно она появляется не в лишней ссылке, а в лишнем(преждевременном) делете. Пока это пространство под убитым объектом никто не заполнил, ее можно считать живой и работающей и никто этого не замечает.
