@Fulcrum_013

Перенесено из темы Уничтожаются ли когда нибудь объекты, реализующие IDisposable?

---

Usaga, В условиях реальной жизни в Dispose каждого класса нужно прописывать разрыв взаимосвязей и освобождение ресурсов перед потерей каждой ссылки вызывать оный Dispose вручную. А то уборка рискует просто не состояться. Это кстати причина по которой из профессиональных языков GC выбросили еще в начале 80-х.

0

@Usaga

Fulcrum_013, это чушь. Содержимое Dispose() дублируется финализатором. Поэтому высвобождение ресурсов произойдёт вне зависимости от вашей ненависти к GC. Взаимосвязи с объектом же, лежат вне его компетенции и к Dispose не относятся.

По этой причине GC стал основой профессиональных языков начиная с середины девяностых. Что, очевидно, очень сильно бесит фанатиков.

0

@Fulcrum_013

Не произойдет вне зависимости от ваших мантр. Потому что без разрыва взаимосвязей при потере ссылки GC не посчитает объекты мусором. Именно поэтому GC и бесполезен и именно поэтому выброшен из всех профессиональных языков в 80-х.

Добавлено через 6 минут
Пруф в студию. Назовите хоть один профессиональный язык имеющий GC или хоть один профессиональный язык спроектированный после 80-х. Таких не существует. На самом деле на сегодняшний день существует ровно 4 профессиональных языка - фортран, паскаль/дельфи, C++ и ада.
Или вы считаете что Страуструп, Хейлсберг и Ишбиа которые независимо друг от друга выбросили GC из проектируемых ими языков тоже типа фанатики и типа тупее вас?

Добавлено через 3 минуты
Для решения задачи разрыва взаимосвязей и высвобождения ресурсво вовремя необходимо просматривать мусор образующийся при потере каждой ссылки инстантно. Другого способа гарантировать возможность уборки и высвобождения объектов не существует.
Это кстати так о птичках кастрированный по самые немогу unique_ptr.

0

@Usaga

Произойдёт. Ибо это я каждый день и вижу. И взаимосвязи к Dispose не относятся. Языки восьмидесятых в восьмидесятых и остались.

Java, C#.

Не забываем, что именно Хейлсберг является автором C#. Так что тупее нас тут только ваша персона.

Добавлено через 1 минуту
Для слабоумных: "разрыв взаимосвязей" не является "задачей". Это - мелочь.

Dispose никакого отношения к unique_ptr вообще не имеет. Вызов метода произвольной логикой и механизм уникального владения - разные вещи.

4

@Fulcrum_013

И сами приводите пример где этого не происходит.

Добавлено через 36 секунд
Ну дак и шарп предназначался на замену вижуал васику а не как професииональный язык.

Добавлено через 1 минуту
Для слабоумных - эта "мелочь" абсолютно анологична ручному вызову delete для каждой ссыылки и делает GC ненужным от слова совсем.

Добавлено через 2 часа 53 минуты
Вы вообще читать то умеете? Там про using написано вызывающий Dispose а не про сам Dispose.

Добавлено через 1 час 9 минут
C каких пор они стали профессиональными языками или хотя бы языками универсального назначения?

0

@Usaga

Я вам уже раз двадцать сказал, что происходит. Но вы даже пример запускать не стали.

Именно как профессиональный, каким и стал почти сразу.

Никакой аналогии с удалением объекта (delete) и ручным расписыванием конструкторов в каждом классе.

И опять же это разные вещи. Совсем.

Со дня их создания.

0

@Fulcrum_013

Да что вы. Шарп вообще со дня своего проектирования создавался как замена для визуал бейсика - т.е. средство для кастомизации предназначенное для непрофессионалов. А у явы с первого же дня ее существования реклама типа что профи для нее не нужны.
Один в один unique_ptr при подобном применении точно так же в конце скопа/при вылете экскепшина вызывает delete как using Dispose

Добавлено через 2 минуты
без вызова Dispose никакой уборки не происходит. Так что хватит расказывать сказки про то что GC что то может.

Добавлено через 1 минуту
Вы про С++? Да никакой. А в языках с GC полная. GC потому и выбросили что для управления ресурсами и взаимосвязми все равно нужен аналог деструктора и его вызов после каждой ссылки, иначе в реалиях ООП никакой уборки вообще не будет, а решение вопроса с ресурсами/взаимосвязяеми делает сканирование живых ненужным. А в С++ пошли по пути автоматизации именно этого процесса.

0

@Usaga

Да, представьте. На этих языках можно создавать сложные вещи и не париться лишний раз о shared_ptr.

Таки unique_ptr инкапсулирует владение объектом, позволяет это владение передавать дальше. Это его основная суть. А уделение по выходу из скоупа - бонус. Разница тут существенная: dispose, как правило, перевызывает код с освобождением ресурсов, который, если не был вызван самим dispos'ом, будет или вызван финализатором при сборке мусора, либо вообще такие ресурсы без "очистки" могут быть удалены. Т.е. вызов Dispose только уточняет момент, когда ресурсы надо высвободить. Если забыть это сделать, то такое высвобождение всё равно произойдёт и утечек не будет. А теперь покажите мне такое же, но без unique_ptr.

Вы прикидываетесь дураком или нет? Dispose не мешает сборке и не начинает её. Этот метод - часть бизнес-логики, способ сказать объекту, что он переводится в неактивное состояние. Это может быть что угодно. Даже смена курсора с часиков песочных на обычную стрелку (да, даже такое практикуется) или возврат контролов из заблокированного состояния. Никакой связи со сборкой мусора нет и в помине. Запустите мой пример с окошком и байнднгами и лично посмотрите.

Пока вы этот пример не запустите, все ваши слова - трёп тупой и пустой.

Никто никого не выбрасывал. Я вам показал код, где в C# нет никаких деструкторов и умных указателей. И всё чётко и корректно работает. Вы же очконули этот пример запускать, ибо окажется, что вы не правы в своих словах.

0

@Fulcrum_013

Но на каждом шагу парится о том о чем нужно парится один раз при определении типа взаимосвязи.
Где? точно такой же вызов аналога деструктора при помощи костыльной пародии на умный указатель. И какм боком в этом примере GC к обеспечению корректности поведения?

Добавлено через 1 минуту
Так деструктор это тоже самое.

0

@Usaga

Ни о чём париться не надо. Примеры вам были показаны. Запарки там нет. Всё просто работает.

Никаких деструкторов, костылей и умных указателей. Ни одного.

Добавлено через 18 секунд
Нет. Это уже про полное уничтожение объекта.

0

@Fulcrum_013

Есть и прямая. Без разрыва взаимосвязей производимых при деактивации объекта его уборка GC в общем случае невозможна.

Добавлено через 2 минуты
Вообще то уничтожением буфера объекта занимается ни разу не деструктор. Деструктор только подготавливает объект к безопасному уничтожению буфера. Т.е реализует абсолютно тe же бизнес-логики что и Dispose.
Еще раз - освойте матчасть перед тем как нести ваш бред.

0

@Usaga

И тем не менее, в показанном примере такая сборка производится.

Dispose не уничтожает никаких буферов. Этот метод допустимо вызывать произвольное количество раз, а потом продолжать пользоваться объектом дальше, если он сам это позволяет. Кто тут матчасть не знает, но строит из себя профессионала STL-лописца?

0

@Fulcrum_013

Так и деструктор не уничтожает буфер объекта. Это делает operator delete.

Добавлено через 28 секунд
Дык тоже самое с явным вызовом деструктора.

0

@Usaga

Который идёт рука об руку с деструктором. Dispose никакой сборке не предшевствует. Разницу видите?

Добавлено через 28 секунд
Явно деструктор только мракобесы вызывают)

0

@Fulcrum_013

Вы не знаете.

0

@Usaga

Да, да. Но подтверждения своих тупых слов, почему-то, привести не можете вы. Как это так?

0

@Fulcrum_013

Ну правильно. Потому что перед удалением буфера operator delete должен убедится в безопасности этой операции а соответсвенно она автоматически вставляется неявно.

Добавлено через 1 минуту
Тупые и ничем не подтвержденные слова и вообще какой то бред здесь виден только от вас.

Добавлено через 2 минуты
Ну вот GC и заставляет на каждом шагу занимаеться оным мракобесием с вызовом Dispose аки в паскале где деструктор вызывается только явно.
А в плюсах это достаточно только в библиотечном коде контейнеров делать.

0

@Usaga

Но Dispose и using не про удаление.

Обвинителем выступили вы и вы же не смогли показать ни одного вменяемого примера. Только ерунду. Я вам рабочий код на каждое ваше тупое замечание предоставил.

Он не заставляет. Этот метод нужен только для неуправляемых ресурсов, и не чтобы они не утекли (их GC отпустит), а чтобы их раньше освободить.

0

@Fulcrum_013

А так же для любых объектов которые имеют/могут иметь подчиненные объекты владеющие ресурсами/имеющие ссылки из за пределов дерева подчинения, т.е. альтернативные трассы на рут. В реалиях ООП и тем более паттерна композит, который лежит в основе всего и вся на сегодняшний день, это абсолютно все объекты моделирующие сущности предметной области.

0

@Usaga

Нет.

0