|
Управление памятью - проклятие Сишарпа
|
|||
---|---|---|---|
#18+
Абстракции текут как не знаю что... 1. Рекомендуют реализовывать IDisposable для всех классов-потомков, унаследованных от классов, реализующих IDisposable. А также, если класс содержит поля с типами, реализующими IDisposable. У меня, конечно, мало опыта, но что-то мне подсказывает, что для более-менее сложной системы это будут чуть менее, чем все классы. Да? 2. Реализая освобождения ресурсов сложнее и гораздо сложнее, чем в том же С++, который, якобы, в плане управления памятью сложнее, чем С#. Ведь в C# надо реализовать Dispose и финализаторы-деструкторы со сложными правилами и порядком их вызова , а в С++ - только деструкторы и без всякой возни с Dispose(bool) и кучей правил, типа "X DO NOT make the parameterless Dispose method virtual.". Ребята, так получается, что в С++ с памятью работать проще, если программа выходит за рамки своей "Hello World"-песочницы (что происходит почти всегда в нормальных приложениях) и начинает работать как взрослая, потребляя неуправляемые ресурсы и работая с другими приложениями? 3. Сборщик мусора сам заботится об освобождении ресурсов, но вдруг и внезапно это стало "bad coding style". Правильные пацаны всё делают руками и бьют по рукам тех, кто доверяет сборщику мусора. Поэтому у правильных пацанов в конторах все ресурсы освобождаются руками и код пестрит вызовами Dispose и using. Я не понимаю - кто-нибудь, объясните мне - в чём тогда заключается плюс сборщика мусора, если в любой более-менее сложной программе надо памятью управлять самому? Сборщик мусора может управлять только самыми базовыми объектами, что даёт минимальные преимущества. И эти преимущества с лихвой покрываются сложностью и количеством правил "правильного" управления неуправляемыми ресурсами в C#. Жду ваших рассуждений по этому поводу. Например, "да, так и есть - нас наипали, возвращаемся все на С++". ... |
|||
:
Нравится:
Не нравится:
|
|||
12.06.2014, 06:10 |
|
Управление памятью - проклятие Сишарпа
|
|||
---|---|---|---|
#18+
user7320правил "правильного" управления неуправляемыми 4 однокоренных слова подряд - это вам не хухры-мухры. ... |
|||
:
Нравится:
Не нравится:
|
|||
12.06.2014, 06:11 |
|
Управление памятью - проклятие Сишарпа
|
|||
---|---|---|---|
#18+
А ещё мне нравится, как всякие эрики липперты говорят, типа, то-то и то-то - это "нарушение контракта, и тогда мы ни за что не отвечаем". При этом сами они контракты типа ".NET - платформа с автоматическим управлением памятью" нарушают на каждом шагу. Я понимаю, что надо отличать маркетинговую лабуду "всем срочно бежать на нашу новую платформу программирования" от того, что написано мелким шрифтом ("по правде говоря, наша новая платформа - говно... в ней плюс только - это реализация кучи готовых классов на все случаи жизни, а с управлением памятью вы ещё попортите себе нервы побольше, чем на С++ - ведь мало того, что оно сложнее, чем на С++, так ещё её реализация и скрыта от вас по большей части за недоступным для вас сборщиком мусора")... Но на самом деле я не хочу это понимать. Так и хочется ответить в духе ... |
|||
:
Нравится:
Не нравится:
|
|||
12.06.2014, 06:32 |
|
Управление памятью - проклятие Сишарпа
|
|||
---|---|---|---|
#18+
http://www.sql.ru/forum/actualutils.aspx?action=gotomsg&tid=809186&msg=9843540 Да если и не использовать конструкцию using или Dispose() все равно ресурсы гарантировано освободятся, ибо в типовой реализации есть защита от идиота. А как использовать ваш тип, решайте сами, или придерживаться типового паттерна , или изобрести самому, но во втором случае мату будет предостаточно в ваш адрес, хотя я и подозреваю и в первом так же, ибо вам лень заглянуть, туда, куда программисты постоянно заглядывают.. Хе-хе... А если использовать паттерн неправильно (то бишь "изобрести свой"), то "защита от идиота" и в этом случае гарантирует освобождение ресурсов? Т. е., если я буду хаотично вызывать всякие Dispose и SupressFinalize, а потом продолжу работу, вполне может быть, что память просто не освободится? Или как? ... |
|||
:
Нравится:
Не нравится:
|
|||
12.06.2014, 06:41 |
|
Управление памятью - проклятие Сишарпа
|
|||
---|---|---|---|
#18+
"Защита от идиота" - это тоже абстракция. А в C# абстракции протекают больше всех. ... |
|||
:
Нравится:
Не нравится:
|
|||
12.06.2014, 06:41 |
|
Управление памятью - проклятие Сишарпа
|
|||
---|---|---|---|
#18+
user7320И эти преимущества с лихвой покрываются сложностью и количеством правил "правильного" управления неуправляемыми ресурсами в C#. ничего сложного нет, если понимать механизмы ... |
|||
:
Нравится:
Не нравится:
|
|||
12.06.2014, 08:38 |
|
Управление памятью - проклятие Сишарпа
|
|||
---|---|---|---|
#18+
Изопропилuser7320И эти преимущества с лихвой покрываются сложностью и количеством правил "правильного" управления неуправляемыми ресурсами в C#. ничего сложного нет, если понимать механизмы И с С++ не стоит переходить на всякие джавы и сишарпы, если у тебя 20 лет опыта в нём и тулзы с либками на все случаи жизни сделаны и отточены. ... |
|||
:
Нравится:
Не нравится:
|
|||
12.06.2014, 10:47 |
|
Управление памятью - проклятие Сишарпа
|
|||
---|---|---|---|
#18+
user73201. Рекомендуют реализовывать IDisposable для всех классов-потомков, унаследованных от классов, реализующих IDisposable. А также, если класс содержит поля с типами, реализующими IDisposable. У меня, конечно, мало опыта, но что-то мне подсказывает, что для более-менее сложной системы это будут чуть менее, чем все классы. Да? Нет. У меня опыт около 10 разных проэктов (и больших, и маленьких). Я ни разу не реализовывал этот самый IDisposable, но стирать - ненужное его использование (написанное выпускниками) - стирал. Есть ряд прикладых проэктов, в которых не пишутся модули, которые будут отдаваться для использования еще кем-то. И поэтому, не составляет труда закрыть за собой сокет или освободить файл - тогда, когда надо, а не из расчета, что кто-то обязательно обернет в using , и будет ожидать правильного поведения. Ну просто никогда не будет этого. ... |
|||
:
Нравится:
Не нравится:
|
|||
12.06.2014, 11:21 |
|
Управление памятью - проклятие Сишарпа
|
|||
---|---|---|---|
#18+
user73202. Реализая освобождения ресурсов сложнее и гораздо сложнее, чем в том же С++, который, якобы, в плане управления памятью сложнее, чем С#. Ведь в C# надо реализовать Dispose и финализаторы-деструкторы Правильнее было бы использовать не слово "надо" - потому, что обычно (95% кода и задач) - не надо. А фразу "можно если нужно" :-) ЗЫ - Ни разу не писал финализатора (в реальном проэкте). Тем более, что в тех же книжках пишут что он иногда не вызвается.... :-) ... |
|||
:
Нравится:
Не нравится:
|
|||
12.06.2014, 11:36 |
|
Управление памятью - проклятие Сишарпа
|
|||
---|---|---|---|
#18+
user7320 3. Сборщик мусора сам заботится об освобождении ресурсов, но вдруг и внезапно это стало "bad coding style". Правильные пацаны всё делают руками и бьют по рукам тех, кто доверяет сборщику мусора. Поэтому у правильных пацанов в конторах все ресурсы освобождаются руками и код пестрит вызовами Dispose и using. Dispose и using - вовсе не освобождают ресурсы, по крайней мере они с вызовом Сборщика ни как не связаны - они сами по себе, он сам по себе. Вызывать Dispose для класса, который не имеет внешних ресурсов (файлов, сокетов, постронних нативных длл) - это не смертельно, но не имеет никакого практического смысла. ... |
|||
:
Нравится:
Не нравится:
|
|||
12.06.2014, 11:40 |
|
Управление памятью - проклятие Сишарпа
|
|||
---|---|---|---|
#18+
user73201. Рекомендуют реализовывать IDisposable для всех классов-потомков, унаследованных от классов, реализующих IDisposable. Да ну? http://msdn.microsoft.com/ru-ru/library/ms244737.aspx IDisposable is not implemented correctly. Some reasons for this problem are listed here: IDisposable is re-implemented in the class. Finalize is re-overridden. Dispose is overridden. Кто рекомендует? Ткните пальцем. С указанием ссылки. ... |
|||
:
Нравится:
Не нравится:
|
|||
12.06.2014, 11:44 |
|
Управление памятью - проклятие Сишарпа
|
|||
---|---|---|---|
#18+
D129Dispose и using - вовсе не освобождают ресурсы, по крайней мере они с вызовом Сборщика ни как не связаны - они сами по себе, он сам по себе. И это тоже. ТС не раз уже демонстрирует кашу в голове по самым основам. В данном случае он не видит разницы между managed и unmanaged ресурсами. Остается только рекомендовать читать до полного просветления: http://msdn.microsoft.com/en-us/magazine/cc163392.aspx По этой ссылке, кстати: When you derive from a disposable type, and that derived type does not introduce any new resources, then nothing special needs to be done. The base type IDisposable implementation will take care of cleaning up its resources and your subclass can be blissfully ignorant of the details ... |
|||
:
Нравится:
Не нравится:
|
|||
12.06.2014, 11:49 |
|
Управление памятью - проклятие Сишарпа
|
|||
---|---|---|---|
#18+
user7320, Ну че опять завыл, чем сборщик не нравится и с какого боку тут idisposable я щас взорву мозг опять.. Код: c# 1. 2. 3.
а если учесть что конструктор типа, это такой же по существу метод, сборщик может удалить уже созданный объект в куче, не дожидаясь окончания работы конструктора.... ... |
|||
:
Нравится:
Не нравится:
|
|||
12.06.2014, 22:11 |
|
Управление памятью - проклятие Сишарпа
|
|||
---|---|---|---|
#18+
Где-то в степи, Как тебе, нормальный фильм ? Всё же, в Visual Basic есть и преимущества перед C#. Например, названия ключевых слов. В C# какое-то непонятное abstract class, а в VB - MustInherit. В C# - abstract method, а в VB - MustOverride. Короче, говорящие названия в VB. Вобщем, как я понял, стоит собрать всё отсюда и отсюда и слепить что-то типа такого класса . ... |
|||
:
Нравится:
Не нравится:
|
|||
12.06.2014, 23:31 |
|
Управление памятью - проклятие Сишарпа
|
|||
---|---|---|---|
#18+
user7320, Ух ты шалунишка )) авторВсё же, в Visual Basic есть и преимущества перед C#. Например, названия ключевых слов. В C# какое-то непонятное abstract class, а в VB - MustInherit. В C# - abstract method, а в VB - MustOverride. Короче, говорящие названия в VB. тут не ко мне а к Петросяну: Вчера были по три рубля но очень большие, сегодня по пять но маленькие(С) Вы что на него так взъелись, аль уже пришла пора освобождать чтонить? Советую взглянуть на CriticalFinalizerObject SafeHandle для завершения представления картины вселенной.. ... |
|||
:
Нравится:
Не нравится:
|
|||
13.06.2014, 00:09 |
|
Управление памятью - проклятие Сишарпа
|
|||
---|---|---|---|
#18+
Где-то в степи, мозг пациента не выдержит ... |
|||
:
Нравится:
Не нравится:
|
|||
13.06.2014, 00:19 |
|
Управление памятью - проклятие Сишарпа
|
|||
---|---|---|---|
#18+
Да всё началось с того, что я встретил вот эту штуку: http://www.braynzarsoft.net/Articles/index.php?p=VA&article=DirectX-11-with-SharpDX---3:-Initializing-Direct3D-11 Clean Up Even though C# takes care of non-disposed objects and removes them automatically after the program has run, we should not follow the bad coding style to let the .NET runtime do this dirty job. Add a method "DisposeObjects()" to your class and call Dispose on the things we created above: Код: c# 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11.
Call it in the main method after you ran the RenderLoop. Это статья про SharpDX. SharpDX - это набор обёрток managed над DirectX. И в этом SharpDX по-страшному используются всякие диспоузы. Особенно мне непонятно их использовании при завершении работы программы - нафига? Разве может быть, что что-то не освободится, когда программа завершается? Как это выглядит? Как кусок "зависшей" оперативки, которая недоступна больше никаким приложениям? ... |
|||
:
Нравится:
Не нравится:
|
|||
13.06.2014, 05:04 |
|
Управление памятью - проклятие Сишарпа
|
|||
---|---|---|---|
#18+
user7320, Direct3D - весь на COM построен. Dispose - для своевременного освобождения ссылок на COM- объекты(неуправляемые ресурсы). При использовании c++ - либо руками relesase вызывать нужно(и не забывать), либо smart-указатели(unique_ptr , shared_ptr и weak_ptr) К управлению памятью непосредственно эти Dispose отношения не имеют И в конце работы - эти Dispose не память освобождают, а ресурсы Direct3D/GPU. В принципе, конечно при завершении приложения все ресурсы должны освобождаться, тем не менее утечки могут иметь место. Обычные файлы ты ведь закрываешь перед завершением приложения? ... |
|||
:
Нравится:
Не нравится:
|
|||
13.06.2014, 10:17 |
|
Управление памятью - проклятие Сишарпа
|
|||
---|---|---|---|
#18+
user7320, мне не нравится авторОсобенно мне непонятно их использовании при завершении работы программы - нафига Это как то по ватному ( в вашем стиле) посрал - и ушел.... Есть же общепринятые нормы, корректно завершить программу, освободить дескрипторы ядра ( хотя и виндовс гарантирует освобождение при завершении процесса), а не лепить тупой аборт - типа все педерасты.. Вы вообще с вашим нигилизмом можете забыть o disposable (худо бедно промышленные типы позволяют терпеть оттяжку, и есть у них защита от дурака), как о атрибуте зажравшейся пиндостании.. По имейте на будущее такую мысль создать свой отечественный язык с русскими ключевыми словами, равно как и компилятор который будет компилить код по отечественный процессор, заточенный под отечественную операционную систему. Я тогда вам руку пожму )) и прощу Вам все истерики..)) ... |
|||
:
Нравится:
Не нравится:
|
|||
13.06.2014, 10:18 |
|
Управление памятью - проклятие Сишарпа
|
|||
---|---|---|---|
#18+
user7320Особенно мне непонятно их использовании при завершении работы программы - нафига? Разве может быть, что что-то не освободится, когда программа завершается? Да легко. Утечка unmanaged памяти - обычное дело при работе, например, с COM Interop. Например, при работе с Excel через COM Interop. На больших объемах (писал я как-то обработку нескольких сотен экселин каждая по ~50 тыс. строк) это видно очень хорошо, и утечка сохраняется даже после корректного закрытия экземпляра экселя. А при заворачивании всего, что только можно в IDisposable/using (с вызовом Marshal.ReleaseCOMObject, занулением ссылок, и двойным вызовом GC.Collect внутри) утечки прекращаются. А как выше уже писали, DirectX весь построен на COM. ... |
|||
:
Нравится:
Не нравится:
|
|||
13.06.2014, 10:35 |
|
Управление памятью - проклятие Сишарпа
|
|||
---|---|---|---|
#18+
Где-то в степиВы вообще с вашим нигилизмом Это не нигилизм, а просто подход в стиле "чукча не читатель". У ТСа же пробелы в предметной области, которые он упорно не хочет заполнять. Где-то в степиПо имейте на будущее такую мысль создать свой отечественный язык с русскими ключевыми словами, равно как и компилятор который будет компилить код по отечественный процессор, заточенный под отечественную операционную систему. Я тогда вам руку пожму )) и прощу Вам все истерики..)) Вот тут и частично вот тут . ... |
|||
:
Нравится:
Не нравится:
|
|||
13.06.2014, 10:41 |
|
Управление памятью - проклятие Сишарпа
|
|||
---|---|---|---|
#18+
user73201. Рекомендуют реализовывать IDisposable для всех классов-потомков, унаследованных от классов, реализующих IDisposable. Ничего подобного. Кинь валенком в того, кто так сказал. user73202. Реализая освобождения ресурсов сложнее и гораздо сложнее, чем в том же С++ Смотря каких ресурсов. Если управляемых - то заботится ненужно, GC сам всё уберёт. На то они и управляемые. А вот если ресурсы неуправляемые, если они изначально писаны в нативе, если они протащены в мир дотнета из жуткого неуправляемого мира, как верблюд через угольное ушко - тогда звиняй, приходится танцевать с бубном. user7320Ведь в C# надо реализовать Dispose и финализаторы-деструкторы Финализаторы не нужны почти никогда. Dispose - очень редко. user73203. Сборщик мусора сам заботится об освобождении ресурсов Да. Но, как уже сказано, ГЦ не способен узнать, что там происходит в неуправляемом мире, поэтому Dispose и using необходимы для обёрток над неуправляемым кодом. IDisposable: What Your Mother Never Told You About Resource Deallocation ... |
|||
:
Нравится:
Не нравится:
|
|||
27.06.2014, 03:45 |
|
Управление памятью - проклятие Сишарпа
|
|||
---|---|---|---|
#18+
petalvik, ну нет никаких танцев с бубном, если есть понимание принципов работы ... |
|||
:
Нравится:
Не нравится:
|
|||
27.06.2014, 08:30 |
|
Управление памятью - проклятие Сишарпа
|
|||
---|---|---|---|
#18+
надо понимать,что IDispose это не есть освобождение, а удобный интсрумент для освобождения. Согласен,что по большому счету он нужен для неуправляемых ресурсов, возможно отписки от событий и тд. Финализатор нужен почти всегда для реализации dispose паттерна, не вижу в этом ничего плохого. ... |
|||
:
Нравится:
Не нравится:
|
|||
27.06.2014, 12:05 |
|
|
start [/forum/topic.php?fid=20&msg=38668346&tid=1402765]: |
0ms |
get settings: |
8ms |
get forum list: |
13ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
33ms |
get topic data: |
9ms |
get forum data: |
2ms |
get page messages: |
62ms |
get tp. blocked users: |
1ms |
others: | 13ms |
total: | 149ms |
0 / 0 |