Как уничтожить экземпляр класса (объект)?

@Roman Pytkov · Регистрация: 11.03.2019

Студворк — интернет-сервис помощи студентам

Я столкнул с такой проблемой. Я не могу понять как удалять объекты класса(экземляры). Читая интернет я вижу что "мусорщик" должен автоматически удалять те объекты, на которые нет указателя, но у меня это не работает. Подскажите как решить. Вот видео где всё показано, по нажатию кнопки в указатель записывается новый объект, но старый не удаляется, это видно по увеличению кол-ва оперативной памяти занимаемого приложением.

https://www.youtube.com/watch?... e=youtu.be

Кликните здесь для просмотра всего текста

@Usaga · 24.06.2019, 06:49

Сообщение от Fulcrum_013

Оно уничтожает инстанс.

Вам бы с CodeHuligan про goto спорить и не показывать в приличном обществе своё полное непонимание происходящего...

Fulcrum_013, можете показать пример кода, где "инстанст" уничтожается вызовом метода Dispose? Я бы с удовольствием посмотрел.

А так, получается, что вы несёте:

Кликните здесь для просмотра всего текста

C#
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
using System;
 
namespace ConsoleApp2
{
    class DuncanMcLaud : IDisposable
    {
        public void Dispose()
        {
            // Immortality
        }
 
        internal void CheckHealth()
        {
            Console.WriteLine("Still alive");
        }
    }
 
    class Program
    {
        static void Main(string[] args)
        {
            var highlander = new DuncanMcLaud();
 
            highlander.Dispose();
 
            using (highlander) { }
 
            highlander.Dispose();
 
            using (highlander) { /* Да сдохни ты уже, тварь! */ }
 
            highlander.CheckHealth();
 
            Console.Read();
        }
    }
}

@Fulcrum_013 · 25.06.2019, 16:46

Usaga, При любом вызове метода Dispose. Его суть именно в уничтожении инстанса точно так же как и у деструтора. Т.е. буфер приводится в такое состояние когда то что в нем находится уже не является объектом в терминологии ООП - т.е. сущностью моделирующей объект предметной области, а соответственно память буфера сразу после этого пригодна для переиспользования. А тривиальный ли деструктор или нет, и безопасен ли его повторный вызов - это уже к делу вообще не относится и зависит от конкретного класса инстанса и деталей реализации.

Добавлено через 17 минут
Usaga, Сядьте один раз и отделите котлет от мух. Вот к примеру что вы хотели показать этим куском быдлокода? Вы это в терминах ООП или других разделорв компьютерных наук объяснить можете? Не можете. Так что несете вы только всякую чушь ни о чем, абсолютно никак не пересекающуюся ни с обсуждаемой темой ни вообще с реальной действительностью.

Еще раз - учите матчасть и не морочьте людям голову своими околовсяческими бреднями высосанными из мифологии ютуба.

@Usaga · 25.06.2019, 17:35

Fulcrum_013, я вам показал, что экземпляр объекта никак не страдает и не изменяется при вызове Dispose(). И ни вопроса ТС, ни ваш пассаж о Dispose() к предметной области не относится.

Метод Dispose() к удалению экземпляра класса не относится вообще никак.

@Fulcrum_013 · 25.06.2019, 18:20

Usaga, Опять двойка. Инстанс после вызова деструктора, роль коего в нетах исполняет Dispose, считается несуществующим по правилам ООП. А как там оно реализовано в плане безопасности ловления граблей повторного доступа к обломкам которые остались в буфере к делу не относится.
пример.

C++
1
2
3
4
5
6
class foo{
   int *a;
public:
    foo() : a{ new int[1000]; }
    ~foo() { delete[] a;}
}

при такой реализации при повторном вызове деструктора получим экскепшин от operator delete[]

C++
1
2
3
4
5
6
7
8
9
class foo{
   int *a;
public:
    foo() : a{ new int[1000]; }
    ~foo() { 
        delete[] a;
        a = nullptr;
   }
}

а вот при такой хоть миллион раз деструктор вызывайте.
Но факт того что инстанс уничтожен первым вызовом деструктора от этого не меняется.
Точно так же и c Dispose с той разницей что у Dispose проверка уничожался ли инстанс ранее пишется вручную а в данном примере она под капотом operator delete[].

@Cupko · 25.06.2019, 18:41

Fulcrum_013, это троллинг какой-то?

Сообщение от Fulcrum_013

роль коего в нетах исполняет Dispose

Откуда инфа? Ваша цитата:

Сообщение от Fulcrum_013

Usaga, https://docs.microsoft.com/en-... ng-dispose
Вас где забанили то? На гугле или на MSDN? Или и там и там?

Где по ссылке что-то про уничтожение? Есть другая ссылка - кидайте.
Зато там есть интересное замечание:

In C#, you override Object.Finalize by defining a destructor.

Но хочу вас расстроить. Деструктор и Finalize() тоже никакого отношения не имеют.

А теперь в терминах компьютерных наук:
В .NET используется Mark&Sweep(Compact) алгоритм сборки мусора. Про него можете почитать здесь (там как раз с гифками для самых маленьких).
По сути уничтожение объекта с точки зрения ООП происходит в конце Mark фазы сборки мусора, когда граф живых инстансов уже построен, что значит, что остальная память уже не используется. На Sweep(Compact) фазе уже идет дефрагментация памяти (поколений) копированием живых инстансов из одной области в другую.

Так что там с Dispose()?
Еще раз - ничего. Dispose() никак к этому не относится, GC не проверятся и инстансы не уничтожается. Вы можете, для примера, задиспозить любой инстанс в статической переменной и он проживет до конца жизни приложения (AppDomain'а).

Так что там с Finalize()?
Тоже ничего, внезапно! Более того, managed объекты, зарегистрированные для финализации, проживут как минимум еще одну сборку мусора, для освобождения unmanaged ресурсов, прежде чем они уйдут в небытие.

Someone007 · 25.06.2019, 18:46

Fulcrum_013, не позорились бы... Dispose в C# не является аналогом деструктора из C++. И даже Finalizer (так же часто называется деструктором) в C# не является полным аналогом деструктора C++, т.к. мы точно не знаем когда он будет вызван в отличие от деструктора C++ (deterministic destruction в С++ против nondeterministic destruction в C#).

А насчет метода Dispose интерфейса IDisposable, то всё что он может делать, это освобождать внешние unmanaged ресурсы, которые создатель класса прописал в метод Dispose и про которые GC соответственно не в курсе. Экземпляр класса он не уничтожает.

@Fulcrum_013 · 25.06.2019, 18:56

Someone007, Это именно аналог деструктора. И задачи у него те же - разрушение инстанса. Причем это аналог паскалевского/дельфовского деструктора а не какого либо другого. GC никаким образом не автоматизирует работу по уничтожению инстансов вовремя. Он всего лишь управляет переиспользованием освобожденных буферов самым неэффективным способом.

@RunningMan · 25.06.2019, 19:07

Сообщение от Fulcrum_013

Он всего лишь управляет переиспользованием освобожденных буферов самым неэффективным способом

Правильно! за что только этим бездарям из майкрософта деньги платят !

@Fulcrum_013 · 25.06.2019, 19:25

Сообщение от Cupko

По сути уничтожение объекта с точки зрения ООП происходит в конце Mark фазы сборки мусора,

Уничтожение объекта (инстанса) с точки зрения ООП происходит либо при разрыве связи композиция либо по другим условиям вычесленным самим объектом или другим взаимосвязанным с ним объектом.
Рассматривать когда и как нужно произвести уничтожение инстанса нужно с точки зрения ООП потому что это сущность предметной области а не с точки зрения когда типа это делает GC. Потому что GC не предназначен для управления врменем жизни инстансов. Он управляет только памятью - т.е. решает задачу "найти кусок памяти для переиспользования" и не более того. При этом делает это наиболее неэффективным из известных сособом.
А что в плане GC не умеет никому давно не интересно. Потому что в плане обеспечения правил ООП он не умеет вообще ничего и поэтому в профессиональных ооп языках GC вообще никогда не использовался. Только в экспериментальной симула-67 где и была выяснена его абсолютная непригодность для ООП.
т.е. касательно исходной темы вопроса как принудительно удалить инстанс способ есть только один - использовать рукописный аналог паскалевского деструктора, коим является Dispose, для разрушения инстанса (высвобождения ресурсов и т.д.) и точно так же как в паскале вызывать его вручную там где нужно принудительно удалить объект. Разница с паскалем только в том что о переиспользовании буфер с обломками инстанса позаботится GC.

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

Сообщение от RunningMan

Правильно! за что только этим бездарям из майкрософта деньги платят ?

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

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

Сообщение от Cupko

По сути уничтожение объекта с точки зрения ООП происходит в конце Mark фазы сборки мусора, когда граф живых инстансов уже построен,

В подавляющем большинстве случаев без предварительного принудительного удаления инстансов по правилам ООП никакая вторая фаза вообще не состоится. Сборщик построит дерево и никого мусором не посчитает. А тем более вовремя.

@Cupko · 25.06.2019, 20:50

Fulcrum_013, теперь я начинаю понимать ваши мысли.

Вы как-то взяли и размазали по всем уровням абстракции слово объект. + у вас нет понимания как работает CLR и GC конкретно в .NET. Не в симуле, не в лиспе, не где либо еще, а конкретно в .NET. Суть в том, что сборщики мусора бывают разные, фреймворки бывают разные и с разными границами ответственности. Касательно .Net - вы абсолютно не правы.

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

Есть объект на уровне кода. Например, new MyObject().DoSomething(). Время жизни которого ограничено областью видимости, или временем жизни агрегата или пока вы явно не уничтожите его (как ваш пример вне .Net)

Есть объекты на уровне CLR (да-да, вполне себе объекты с полями и методами (объекты типа)), которыми и управляет GC, по которым он строит графы и которые он инициализирует в памяти.

Итак, в нашей дискуссии есть 2 момента:
1: метод Dispose() (именно он, и никакой другой) не относится к времени жизни объекта по определению (никакого из вышеперечисленных). Это не деструктор, не его аналог в .Net - это всего лишь один единственный метод IDisposable интерфейса с одним единственным предназначением - освободить unmanaged ресурсы вместо финализатора. Всё.
2: Есть такая штука, как инверсия управления. Это есть отличительная черта (необходимое свойство) любого фреймворка (в том числе .Net). Вся суть в ней в том, чтобы отдать на откуп управление чем-либо (временем жизни, DB-соединениями, потоками и др.). Касательно .NET - фреймворк управляет временем жизни CLR-объектов полностью. Начиная от выделения памяти, заканчивая освобождения этой памяти для других объектов. Именно поэтому, специально, в .Net нет деструкторов и их аналогов, ибо мы отдаем управление созданием и удалением объектов в памяти CLR.

@Fulcrum_013 · 25.06.2019, 21:32

Cupko, Все что вы перечислили относится к инстансу. Называть его объектом кстати так о птичках некорректно потому что на самом деле он то субъект. Путаницу здесь вносит именно то что как instance так и object переводится как объект. Только object при этом ни разу не соответсвует ручкоязычному термину объект в терминах ООП. ему соответсвует именно instance. и вот именно ими GC не управляет от слова совсем. термину же object используемому в описании яп гораздо более соответствует термин ресурс. И вот тогда все становится сразу понятно.
А от того где оно в лиспе нете или каком еще лисапете суть GC не поменяется. Это устаревший эмулятор аппаратного стека изобретенный для памяти на лентах и ничто другое. Ничем кроме высвободившихся буферов памяти он управлять не способен а тем более жизненным циклом и взаимосвязями инстансов. Потому что разрушение инстаса это такая же операция как и вызов любого метода, а равно и вносит изменения в среду, которые оказывают влияние на другие инстансы отслеживающие изменение среды. А соответственно такие действия не могут быть отложены до уборки которая может вообще не состоятся без произведения оных действий вовремя.
Т.е. время жизни инстансов - это епархия исключительно ООП. И ему сугубо фиолетово что и когда сделают потом с буфером в котором жил убиенный инстанс. Для ООП важно отсутсвие у оных убиенных инстансов загробной жизни а не то как и будет ли вообще переиспользован буфер или память реально бесконечная.
А менеджер памяти занимается исключительно обеспечением переиспользования буферов. и ему сугубо фиолетово кто там вообще жило и как именно и когда того кто там жил убили.
Что же касается жабы то в этой ошибке природы по незнанию поймали те же грабли как и в симуле, потому что симула имела очень ограниченное хождение в европейских академических кругах, но никак не в америках где ява была первой попыткой создания профессионального ООП языка (все остальные профессиональные языки с поддержкой ООП спроектировали европейцы). И соответственно когда это выяснилось попытались прикрутить костыли в виде финализаторов и мягких ссылок, которые ничего не исправляют в плане непригодности к автоматическому управлению временем жизни инстансов, а только снижают и без того напрочь отстутствующую эффективность менеджера памяти, потому как для выполнения финализаторов к тому времени когда это что мертвому припарка в плане соблюдения правил ООП, требует обхода не только живых но и мертвых. При этом у GC концепция владения перевернута по сравнению с концепцией композиции используемой в ООП. А соответсвенно ни о какой реализации правил ООП при помощи GC не может быть и речи. Это реализуется только инстантным обходом убиенных с убивством композированных инстансов. И это именно то что делает кастомизируемая автоматика в профессиональных языках. Там же где синтаксис не позволил добавить такую автоматику (для нее требуется объявление перемнных в скопе а не в отдельной секции). GC выбросили поскольку ручной вызов деструкторов (специальный метод разрушающий инстанс) для инстансов выходящих из скопа все равно необходим и при использовании GC, иначе правила ООП собблюсти невозможно. При этом возврат динамических буферов менеджеру памяти по ходу пьессы оказался гораздо эффективней. Хотя бы потому что не имеет накладных расходов на содержание живых которых в ООП всегда гораздо больше чем мертвых. Т.е. суть - в ООП правила времени жизни определяются строго, в отличии от каши в этом плане ФП. Соответственно с концепцией композиции и агрегации список инстансов подлежащих уничтожению всегда известен заранее и никакого сканирования для его построения не нужно в принципе.
Но именно эта ошибка допущенная в яве пошла в обучение в школах аки предмет национальной гордости (догоним и перегоним европу типа). И именно потому что жаба пошла в школы шарп и есть жаба++ кое-как адаптировання к визуальному формошлепству а не что либо другое. Потому что в офисе скриптовым языком дожно быть что то основанное на том что учат в школах. Таковы реалии америк.

Но это не значит что GC используемый в net чем то отличается от GC который был в лиспе. Алгоритм сканирования тот же. Все остальное не более чем костыли и попытки оптимизации. Но сколько не оптимизируй то что в принципе непригодно пригодным оно не станет.
Поэтому управление жизненным циклом инстансов в нет как и влюбом другом языке не имеющем средств автоматики управления жизненным циклом ресурсов осуществляется исключительно вручную.

@Cupko · 25.06.2019, 21:51

Fulcrum_013, вы, как будто, инженер впавший в кому 20 лет назад и вышедший из неё только сегодня. Технологии шагнули далеко вперед, и, вместе с ними, сборщики мусоров, языки, рантаймы и т.д. Если вы суслика не видите, то это не значит, что его нет. Это всё работает. Причем хорошо работает. Я не парюсь вообще насчет памяти занимаемой инстансами объектов в .NET и никогда не парился. Всё что вы пишите про сравнение, про историю, про другие языки - всё болтология. Ни одной ссылки на документацию, ни одного реального примера из .NET. Читайте-развивайтесь сами, вас не пробить.

@HF · 25.06.2019, 22:23

Не по теме:

Человек словно форумом ошибся, но упорно пытается доказать верность своих знаний в другой области.
А спорить про термины/названия в среде, где 99% программистов только так и говорят - это вообще глупо. Мне не нравится что все называют что-то Так, но если я буду упорно говорить по другому - меня или не поймут, или перестанут общаться, считая идиотом.

@Fulcrum_013 · 25.06.2019, 22:36

Сообщение от Cupko

Технологии шагнули далеко вперед

Да есть такое. Давно существует высокоэффективная кастомизируемая автоматика управления жизненным циклов интсансов и их взаимосвязями которая обеспечивает и свервысокоэффективное управление памятью..

Сообщение от Cupko

и, вместе с ними, сборщики мусоров, языки, рантаймы и т.д.

Остались в 60-х. А сейчас сохранились только в анахронизмах типа явы и шарпа.

Сообщение от Cupko

Если вы суслика не видите, то это не значит, что его нет.

На самом деле суслика не видите вы. А он действительно есть. К примеру как с лисповским так и с жабошарповским эмулятором стека вместо использования аппаратного стека и кучи невозможно создать многопоточные приложения. Возможна только эмуляция однопотока средствами мультипотока. Это по вашему прогресс?

Сообщение от Cupko

Ни одной ссылки на документацию, ни одного реального примера из .NET.

А в .Net потому и .Net что никакого автоматического управления инстансами в ней нет в отличии от современных профессиональных языков.

@Cupko · 25.06.2019, 22:43

Сообщение от Fulcrum_013

Да есть такое. Давно существует высокоэффективная кастомизируемая автоматика управления жизненным циклов интсансов и их взаимосвязями которая обеспечивает и свервысокоэффективное управление памятью..

Если это сарказм, то сейчас вообще "свервысокоэффективное управление памятью.." не важно. Сейчас сервера с терабайтами памяти на борту, и не важно когда вы там свои 8 байт очистите.

Сообщение от Fulcrum_013

Остались в 60-х. А сейчас сохранились только в анахронизмах типа явы и шарпа.

Анахронизм, как раз таки, в ручном выделении/высвобождении памяти

Сообщение от Fulcrum_013

На самом деле суслика не видите вы. А он действительно есть. К примеру как с лисповским так и с жабошарповским эмулятором стека вместо использования аппаратного стека и кучи невозможно создать многопоточные приложения. Возможна только эмуляция однопотока средствами мультипотока. Это по вашему прогресс?

Да, это прогресс. Это абстракция над ресурсами, которых сейчас "очень много", а время инженера стоит в разы дорожи железа.

Сообщение от Fulcrum_013

А в .Net потому и .Net что никакого автоматического управления инстансами в ней нет в отличии от современных профессиональных языков.

Так что такое "профессиональный язык"? С++?

@Fulcrum_013 · 25.06.2019, 22:50

Сообщение от Cupko

Так что такое "профессиональный язык"? С++?

По большому счету с++ и ада.

@Cupko · 25.06.2019, 22:56

Fulcrum_013, я понимаю вас, честно. У меня даже есть очень хороший друг, пишуший веб-сервисы на С++, и считающий это удобным.
Просто, не нужно отверткой гвозди заворачивать. У всего есть свое применение и ниша, даже у джаваскрипкта (прости господи)

@Fulcrum_013 · 25.06.2019, 23:00

Сообщение от Cupko

Анахронизм, как раз таки, в ручном выделении/высвобождении памяти

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

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

Сообщение от Cupko

У всего есть свое применение и ниша, даже у джаваскрипкта (прости господи)

Это вообще мертвый язык. Америки в "тяжелом" фронте уже на плюсы во всю переходят. Так это еще Native Client нету есть только WASM. Единственное что этот примитивный жаба-анахронизм на плаву держало - отсутствие альтернатив исполняемых в браузере.

@Cupko · 25.06.2019, 23:03

Сообщение от Fulcrum_013

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

Да не важна память с точки зрения предметной области в принципе. Вы не учитваете в объектно-ориентированном дизайне создание/уничтожение объекта вообще. Как-раз таки, сборщик мусора за вас это выполняет, удаляя все объекты из композиции. Зачем вам нужно проходить рекурсивно по корню агрегата удаляя все дочерние объекты, если это не имеет никакого отношения к бизнесу?

@Fulcrum_013 · 25.06.2019, 23:23

Сообщение от Cupko

У меня даже есть очень хороший друг, пишуший веб-сервисы на С++, и считающий это удобным.

И правильно делает. На беке во всю переход от пакетной обработки к интерактивной. А для нее демоны нужны. Ну а отмазка с управлением регионами при которой GC до окончания времени жихни скрипта выжрать отведенные 50-100 метров не успевает тут уже не канает. Так же как и то рояль играет что демон он уже не бааальшой cout << "<html><body> Hello World </body></html>" а полноценный долгоиграющий приложение с полноценными потребностяи в ООП к которым кроме плюсов ниче по большому счету не приспособлено.

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

Сообщение от Cupko

Зачем вам нужно проходить рекурсивно по корню агрегата удаляя все дочерние объекты, если это не имеет никакого отношения к бизнесу?

Потому что GC не в состоянии соблюдать простейшие правила композиции. А именно - композированный объект уничтожается при разрыве ссылки без всяческих оговорок - т.е. независимо от наличия других трасс на рут. Передача владения при композиции запрещена. Этого Net тоже обеспечить не в состоянии.
Не говоря о более сложных случаях когда хозяев несколько и к уничтожению объекта приводит разрыв связи/уничтожение любого из хозяев.
Это уже не касаясь темы управления ресурсами и т.д. которыми GC управлять не способен в принципе. А автоматика плюсов управляет абсолютно так же как и памятью. Потому что построена именно по принципу управления жизненным циклом инстансов владеющих ресурсами, а память рассматривается как вид ресурса чем она и является на самом деле.

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

Сообщение от Cupko

Зачем вам нужно проходить рекурсивно по корню агрегата удаляя все дочерние объекты,

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

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

Сообщение от Cupko

Зачем вам нужно проходить рекурсивно по корню агрегата удаляя все дочерние объекты, если это не имеет никакого отношения к бизнесу?

Потому что для того чтобы удалить подмножество вершин из графа нужно обрубить все ребра торчащие наружу удаляемого подмножества. Такой обход придется сделать как с GC так и без GC. Любые ресурсы всегда торчат наружу потому что не управляются GC. Гарантировать отсутствие торчащих наружу ребер в частных случаях можно только при статической композиции которая в нет отсутсвует как рыба об лед.

Новые блоги и статьи Все статьи Все блоги /
Использование TThread в Lazarus для математических вычислений. Massaraksh7 25.05.2026 Производя рефакторинг своих программ на предмет ускорения их работы, обратил внимание на такой аспект, как сокращение времени матвычислений. Дело в том, что приходится работать с большими матрицами. . .	Модель здравосохранения 18. Чем здоровее работник, тем быстрее выгорает anaschu 24.05.2026 Имитационная модель корпоративного здравоохранения: что показывает математика Сегодня в модели рабочего коллектива на AnyLogic появились три новые механики — выгорание через накопленную усталость,. . .	Модель здравосохранения 17. Планы на выгорание anaschu 23.05.2026 Вот конкретная схема реализации: В классе Работник добавить: накопленнаяУсталость — растёт каждый час работы, снижается в перерывы и болезни коэффициентПрезентеизма — снижает продуктивность. . .	Изменение цветов в палитре gif файла aka фавикона russiannick 23.05.2026 Изменение цветов в палитре gif файла, юзаемого как фавиконка в составе html-файла, помещенная в base64, средствами нативного Java Script, навеянное сном в майский день. Для работы необходим браузер,. . .
Модель здравосохранения 16. Слишком хорошие и здоровые сотрудники уходят, недовольные зарплатой anaschu 23.05.2026 Отладка увольнений и настройка производительности Сегодня во второй половине дня разобрались с механикой увольнений и настроили коэффициент сложности заданий. Вот что было сделано. . . .	Как я стал коммунистом))) Модель сохранения здоровья сотрудников, запись блога номер 15 anaschu 23.05.2026 Внезапно хорошее здоровье сотрудников не нужно капиталистам?))	Модель здравоСохранения 15. Как мы чинили AnyLogic модель рабочего коллектива: сочленение диаграммы состояний болезней и поломок в ресурспул anaschu 23.05.2026 Как мы чинили AnyLogic модель рабочего коллектива Сегодня разобрались с пятью багами, из-за которых модель либо падала с ошибкой, либо давала совершенно бессмысленные результаты. Каждый баг был. . .	Диалоги с ИИ zorxor 23.05.2026 Насколько я понимаю - Вы - Искусственный Интеллект. Это так? Да, всё верно. Я — искусственный интеллект. Я представляю собой большую языковую модель, созданную для помощи в самых разных задачах. . . .

@Roman Pytkov 3 / 3 / 1 Регистрация: 11.03.2019 Сообщений: 42

	Как уничтожить экземпляр класса (объект)? 21.06.2019, 16:48. Показов 29926. Ответов 119 Метки garbage collection, сборка мусора (Все метки) Я столкнул с такой проблемой. Я не могу понять как удалять объекты класса(экземляры). Читая интернет я вижу что "мусорщик" должен автоматически удалять те объекты, на которые нет указателя, но у меня это не работает. Подскажите как решить. Вот видео где всё показано, по нажатию кнопки в указатель записывается новый объект, но старый не удаляется, это видно по увеличению кол-ва оперативной памяти занимаемого приложением. https://www.youtube.com/watch?... e=youtu.be Кликните здесь для просмотра всего текста 1

@Fulcrum_013 2083 / 1575 / 169 Регистрация: 14.12.2014 Сообщений: 13,614
	25.06.2019, 16:46
	Usaga, При любом вызове метода Dispose. Его суть именно в уничтожении инстанса точно так же как и у деструтора. Т.е. буфер приводится в такое состояние когда то что в нем находится уже не является объектом в терминологии ООП - т.е. сущностью моделирующей объект предметной области, а соответственно память буфера сразу после этого пригодна для переиспользования. А тривиальный ли деструктор или нет, и безопасен ли его повторный вызов - это уже к делу вообще не относится и зависит от конкретного класса инстанса и деталей реализации. Добавлено через 17 минут Usaga, Сядьте один раз и отделите котлет от мух. Вот к примеру что вы хотели показать этим куском быдлокода? Вы это в терминах ООП или других разделорв компьютерных наук объяснить можете? Не можете. Так что несете вы только всякую чушь ни о чем, абсолютно никак не пересекающуюся ни с обсуждаемой темой ни вообще с реальной действительностью. Еще раз - учите матчасть и не морочьте людям голову своими околовсяческими бреднями высосанными из мифологии ютуба. 0

@Usaga 14346 / 9440 / 1358 Регистрация: 21.01.2016 Сообщений: 35,574
	25.06.2019, 17:35
	Fulcrum_013, я вам показал, что экземпляр объекта никак не страдает и не изменяется при вызове Dispose(). И ни вопроса ТС, ни ваш пассаж о Dispose() к предметной области не относится. Метод Dispose() к удалению экземпляра класса не относится вообще никак. 0

Someone007 6691 / 4102 / 1607 Регистрация: 09.05.2015 Сообщений: 9,575
	25.06.2019, 18:46
	Fulcrum_013, не позорились бы... Dispose в C# не является аналогом деструктора из C++. И даже Finalizer (так же часто называется деструктором) в C# не является полным аналогом деструктора C++, т.к. мы точно не знаем когда он будет вызван в отличие от деструктора C++ (deterministic destruction в С++ против nondeterministic destruction в C#). А насчет метода Dispose интерфейса IDisposable, то всё что он может делать, это освобождать внешние unmanaged ресурсы, которые создатель класса прописал в метод Dispose и про которые GC соответственно не в курсе. Экземпляр класса он не уничтожает. 0

@Fulcrum_013 2083 / 1575 / 169 Регистрация: 14.12.2014 Сообщений: 13,614
	25.06.2019, 18:56
	Someone007, Это именно аналог деструктора. И задачи у него те же - разрушение инстанса. Причем это аналог паскалевского/дельфовского деструктора а не какого либо другого. GC никаким образом не автоматизирует работу по уничтожению инстансов вовремя. Он всего лишь управляет переиспользованием освобожденных буферов самым неэффективным способом. 0

@Cupko 658 / 595 / 171 Регистрация: 17.07.2012 Сообщений: 1,682 Записей в блоге: 1
	25.06.2019, 20:50
	Fulcrum_013, теперь я начинаю понимать ваши мысли. Вы как-то взяли и размазали по всем уровням абстракции слово объект. + у вас нет понимания как работает CLR и GC конкретно в .NET. Не в симуле, не в лиспе, не где либо еще, а конкретно в .NET. Суть в том, что сборщики мусора бывают разные, фреймворки бывают разные и с разными границами ответственности. Касательно .Net - вы абсолютно не правы. Есть объект на уровне предметной области, время жизни которого ограничено композицией или клиентом породившим объект. Это вы написали и я с этим согласен. Есть объект на уровне кода. Например, new MyObject().DoSomething(). Время жизни которого ограничено областью видимости, или временем жизни агрегата или пока вы явно не уничтожите его (как ваш пример вне .Net) Есть объекты на уровне CLR (да-да, вполне себе объекты с полями и методами (объекты типа)), которыми и управляет GC, по которым он строит графы и которые он инициализирует в памяти. Итак, в нашей дискуссии есть 2 момента: 1: метод Dispose() (именно он, и никакой другой) не относится к времени жизни объекта по определению (никакого из вышеперечисленных). Это не деструктор, не его аналог в .Net - это всего лишь один единственный метод IDisposable интерфейса с одним единственным предназначением - освободить unmanaged ресурсы вместо финализатора. Всё. 2: Есть такая штука, как инверсия управления. Это есть отличительная черта (необходимое свойство) любого фреймворка (в том числе .Net). Вся суть в ней в том, чтобы отдать на откуп управление чем-либо (временем жизни, DB-соединениями, потоками и др.). Касательно .NET - фреймворк управляет временем жизни CLR-объектов полностью. Начиная от выделения памяти, заканчивая освобождения этой памяти для других объектов. Именно поэтому, специально, в .Net нет деструкторов и их аналогов, ибо мы отдаем управление созданием и удалением объектов в памяти CLR. 1

@Fulcrum_013 2083 / 1575 / 169 Регистрация: 14.12.2014 Сообщений: 13,614
	25.06.2019, 21:32
	Cupko, Все что вы перечислили относится к инстансу. Называть его объектом кстати так о птичках некорректно потому что на самом деле он то субъект. Путаницу здесь вносит именно то что как instance так и object переводится как объект. Только object при этом ни разу не соответсвует ручкоязычному термину объект в терминах ООП. ему соответсвует именно instance. и вот именно ими GC не управляет от слова совсем. термину же object используемому в описании яп гораздо более соответствует термин ресурс. И вот тогда все становится сразу понятно. А от того где оно в лиспе нете или каком еще лисапете суть GC не поменяется. Это устаревший эмулятор аппаратного стека изобретенный для памяти на лентах и ничто другое. Ничем кроме высвободившихся буферов памяти он управлять не способен а тем более жизненным циклом и взаимосвязями инстансов. Потому что разрушение инстаса это такая же операция как и вызов любого метода, а равно и вносит изменения в среду, которые оказывают влияние на другие инстансы отслеживающие изменение среды. А соответственно такие действия не могут быть отложены до уборки которая может вообще не состоятся без произведения оных действий вовремя. Т.е. время жизни инстансов - это епархия исключительно ООП. И ему сугубо фиолетово что и когда сделают потом с буфером в котором жил убиенный инстанс. Для ООП важно отсутсвие у оных убиенных инстансов загробной жизни а не то как и будет ли вообще переиспользован буфер или память реально бесконечная. А менеджер памяти занимается исключительно обеспечением переиспользования буферов. и ему сугубо фиолетово кто там вообще жило и как именно и когда того кто там жил убили. Что же касается жабы то в этой ошибке природы по незнанию поймали те же грабли как и в симуле, потому что симула имела очень ограниченное хождение в европейских академических кругах, но никак не в америках где ява была первой попыткой создания профессионального ООП языка (все остальные профессиональные языки с поддержкой ООП спроектировали европейцы). И соответственно когда это выяснилось попытались прикрутить костыли в виде финализаторов и мягких ссылок, которые ничего не исправляют в плане непригодности к автоматическому управлению временем жизни инстансов, а только снижают и без того напрочь отстутствующую эффективность менеджера памяти, потому как для выполнения финализаторов к тому времени когда это что мертвому припарка в плане соблюдения правил ООП, требует обхода не только живых но и мертвых. При этом у GC концепция владения перевернута по сравнению с концепцией композиции используемой в ООП. А соответсвенно ни о какой реализации правил ООП при помощи GC не может быть и речи. Это реализуется только инстантным обходом убиенных с убивством композированных инстансов. И это именно то что делает кастомизируемая автоматика в профессиональных языках. Там же где синтаксис не позволил добавить такую автоматику (для нее требуется объявление перемнных в скопе а не в отдельной секции). GC выбросили поскольку ручной вызов деструкторов (специальный метод разрушающий инстанс) для инстансов выходящих из скопа все равно необходим и при использовании GC, иначе правила ООП собблюсти невозможно. При этом возврат динамических буферов менеджеру памяти по ходу пьессы оказался гораздо эффективней. Хотя бы потому что не имеет накладных расходов на содержание живых которых в ООП всегда гораздо больше чем мертвых. Т.е. суть - в ООП правила времени жизни определяются строго, в отличии от каши в этом плане ФП. Соответственно с концепцией композиции и агрегации список инстансов подлежащих уничтожению всегда известен заранее и никакого сканирования для его построения не нужно в принципе. Но именно эта ошибка допущенная в яве пошла в обучение в школах аки предмет национальной гордости (догоним и перегоним европу типа). И именно потому что жаба пошла в школы шарп и есть жаба++ кое-как адаптировання к визуальному формошлепству а не что либо другое. Потому что в офисе скриптовым языком дожно быть что то основанное на том что учат в школах. Таковы реалии америк. Но это не значит что GC используемый в net чем то отличается от GC который был в лиспе. Алгоритм сканирования тот же. Все остальное не более чем костыли и попытки оптимизации. Но сколько не оптимизируй то что в принципе непригодно пригодным оно не станет. Поэтому управление жизненным циклом инстансов в нет как и влюбом другом языке не имеющем средств автоматики управления жизненным циклом ресурсов осуществляется исключительно вручную. 0

@Cupko 658 / 595 / 171 Регистрация: 17.07.2012 Сообщений: 1,682 Записей в блоге: 1
	25.06.2019, 21:51
	Fulcrum_013, вы, как будто, инженер впавший в кому 20 лет назад и вышедший из неё только сегодня. Технологии шагнули далеко вперед, и, вместе с ними, сборщики мусоров, языки, рантаймы и т.д. Если вы суслика не видите, то это не значит, что его нет. Это всё работает. Причем хорошо работает. Я не парюсь вообще насчет памяти занимаемой инстансами объектов в .NET и никогда не парился. Всё что вы пишите про сравнение, про историю, про другие языки - всё болтология. Ни одной ссылки на документацию, ни одного реального примера из .NET. Читайте-развивайтесь сами, вас не пробить. 2

@HF
	25.06.2019, 22:23
	Не по теме: Человек словно форумом ошибся, но упорно пытается доказать верность своих знаний в другой области. А спорить про термины/названия в среде, где 99% программистов только так и говорят - это вообще глупо. Мне не нравится что все называют что-то Так, но если я буду упорно говорить по другому - меня или не поймут, или перестанут общаться, считая идиотом. 0

@Cupko 658 / 595 / 171 Регистрация: 17.07.2012 Сообщений: 1,682 Записей в блоге: 1
	25.06.2019, 22:56
	Fulcrum_013, я понимаю вас, честно. У меня даже есть очень хороший друг, пишуший веб-сервисы на С++, и считающий это удобным. Просто, не нужно отверткой гвозди заворачивать. У всего есть свое применение и ниша, даже у джаваскрипкта (прости господи) 0