Очередной флуд Fulcrum_013 о бесполезном GC

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

---

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

0

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

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

0

Сообщение от Usaga Поэтому высвобождение ресурсов произойдёт вне зависимости от вашей ненависти к GC.

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

Добавлено через 6 минут

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

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

Добавлено через 3 минуты

Сообщение от amr-now кните мне пальцем. где в этой теме написано, что единственное предназначение Dispose() - принудительно самим программистом из программы дать команду операционной системе закрыть неуправляемые объекты.

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

Сообщение от amr-now Про синтаксический сахар над Dispose - using( F...) {…} тоже надо было упомянуть.

Это кстати так о птичках кастрированный по самые немогу unique_ptr.

0

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

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

Сообщение от Fulcrum_013 Пруф в студию. Назовите хоть один профессиональный язык имеющий GC или хоть один профессиональный язык спроектированный после 80-х. Таких не существует.

Java, C#.

Сообщение от Fulcrum_013 Или вы считаете что Страуструп, Хейлсберг и Ишбиа

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

Добавлено через 1 минуту

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

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

Сообщение от Fulcrum_013 Это кстати так о птичках кастрированный по самые немогу unique_ptr.

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

4

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

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

Добавлено через 36 секунд

Сообщение от Usaga Не забываем, что именно Хейлсберг является автором C#.

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

Добавлено через 1 минуту

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

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

Добавлено через 2 часа 53 минуты

Сообщение от Usaga Dispose никакого отношения к unique_ptr вообще не имеет.

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

Добавлено через 1 час 9 минут

Сообщение от Usaga Java, C#.

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

0

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

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

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

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

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

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

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

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

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

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

0

Сообщение от Usaga Со дня их создания.

Да что вы. Шарп вообще со дня своего проектирования создавался как замена для визуал бейсика - т.е. средство для кастомизации предназначенное для непрофессионалов. А у явы с первого же дня ее существования реклама типа что профи для нее не нужны.

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

Один в один unique_ptr при подобном применении точно так же в конце скопа/при вылете экскепшина вызывает delete как using Dispose

Добавлено через 2 минуты

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

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

Добавлено через 1 минуту

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

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

0

Сообщение от Fulcrum_013 Да что вы.

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

Сообщение от Fulcrum_013 Один в один unique_ptr при подобном применении точно так же в конце скопа/при вылете экскепшина вызывает delete как using Dispose

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

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

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

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

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

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

0

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

Но на каждом шагу парится о том о чем нужно парится один раз при определении типа взаимосвязи.

Сообщение от Usaga Я вам показал код, где в C# нет никаких деструкторов и умных указателей

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

Добавлено через 1 минуту

Сообщение от Usaga Этот метод - часть бизнес-логики, способ сказать объекту, что он переводится в неактивное состояние.

Так деструктор это тоже самое.

0

Сообщение от Fulcrum_013 Но на каждом шагу парится о том о чем нужно парится один раз все равно

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

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

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

Добавлено через 18 секунд

Сообщение от Fulcrum_013 Так деструктор это тоже самое.

Нет. Это уже про полное уничтожение объекта.

0

Сообщение от Usaga Никакой связи со сборкой мусора нет и в помине.

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

Добавлено через 2 минуты

Сообщение от Usaga Это уже про полное уничтожение объекта.

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

0

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

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

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

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

0

Сообщение от Usaga Dispose не уничтожает никаких буферов.

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

Добавлено через 28 секунд

Сообщение от Usaga Этот метод допустимо вызывать произвольное количество раз, а потом продолжать пользоваться объектом дальше, если он сам это позволяет.

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

0

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

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

Добавлено через 28 секунд

Сообщение от Fulcrum_013 Дык тоже самое с явным вызовом деструктора.

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

0

Сообщение от Usaga Кто тут матчасть не знает,

Вы не знаете.

0

Сообщение от Fulcrum_013 Вы не знаете.

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

0

Сообщение от Usaga Который идёт рука об руку с деструктором.

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

Добавлено через 1 минуту

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

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

Добавлено через 2 минуты

Сообщение от Usaga Явно деструктор только мракобесы вызывают)

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

0

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

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

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

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

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

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

0

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

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

0

Сообщение от Fulcrum_013 А так же для любых объектов которые имеют подчиненные объекты владеющие ресурсами/имеющие ссылки из за пределов дерева.

Нет.

0