@Guinness


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


Будут ли они удалены, зависит от наличия какой-либо цепочки ссылок, ведущих на них из корневой ссылки (такой, которая доступна на одном из уровней текущего стека вызовов).

У Завалишина в докладах про Фантом можно послушать про эти проблемы.

Несомненно.

Самое логичное решение, которое я бы и использовал в плюсах. Более того в фреймворке QT, такое поведение зашито в базовый объект QObject. 
Собственно, в данном случае геморрой с удалением не меньший, чем в языках бех GC. Если я правильно понимаю, преимущества мы можем достичь исключительно в тех ситуациях, когда нет такой сложной и запутанной структуры. 
Но в простых я могу использовать умные указатели. Как в общем-то и в сложных ситуациях.

@Guinness


В плюсах -- да, несмотря на ручное управление памятью, существует множество средств для того, чтобы справиться со сложностью: разнообразные умные указатели, RAII и т.п. Если сравнивать с дотнетом, то в случае необходимости управлять "внешними" ресурсами (типа хэндлов к файлам или каким другим ядрёным объектам), то в плюсах писать код даже проще: достаточно деструктора, в то время как в дотнете архитектурно верно развернуть паттерн с деструктором, IDisposable и булевым флагом, чтобы покрыть все сценарии использования (справедливости ради, 99% таких случаев покрыты .NET, поэтому необходимость писать это обычно не возникает).

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

В вопросе управления памятью хороши и явный подход плюсов, и неявный дотнета. Здесь только дельфи в анусе, потому что у неё нет ни того, ни другого.  Только ручками, ручками.

Я про это Атари и талдычу, что надо сначала каким-то образом перевести программу в состояние, чтобы GC мог четко сказать, что данный объект не используется, а это и есть самое трудное, что же касается забытого вызова Free, то в той же Delphi достаточно будет FastMM подключить и прогнать в полном дебаге и будет список мест, где что-то было создано, но не убито. До этой темы я про GC как-то не думал, ну есть в жабе, ей надо, она на серверах живет, сейчас у меня уже сомнения, что от этой технологии реально много пользы, т. к. самый главный код, который может быть весьма нетривиален, надо писать все равно руками.



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



Можно быть покультурнее и не посылать фактически в гугл, перечитывать огромную статью целиком мало кто будет, так что если не трудно, приведи цитату, где описано решение означенной проблемы.



Как раз наоборот, в моем понимании классы именно ссылочные типы. Просто потому что к классу в отличие от структур крайне редко нужно применять присваивание. А вот копировать ссылки нужно часто, и я не вижу никакого смысла реализовывать это через явные указатели. Кстати, не удивлюсь, если именно по таким соображениям в Delphi ввели классы, отодвинув обджекты на обочину.



Да ради бога, но только с правом отключения нафиг.



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

Пока на адекватность среди делфистов претендует только Злоха. Акелло судя по всему совсем не большого возраста, 13?. Касательно Белтара  - тут всё очень запущено.

Добавлено через 26 секунд
Топикстартет упоротый тролль 

Добавлено через 3 минуты
И аватара у Белтара тоже говорящая  

Куда уж нам до вас.
Кстати, аватарку по идее бы надо сменить, т. к. подпись поменялась.

Beltar, хватит троллить, завязывай 

@Beltar


Во-первых, задача далеко не всегда формулируется в форме "удалить объект предметной области". Чаще -- "убрать упоминание объекта отсюда", "изменить на ссылку на другой объект" и т.п. Это видно на примере с графом.

Во-вторых, ты даже упомянутую выше задачу удаления юзера в дельфи будешь решать с большим трудом, потому что "события" в дельфи поддерживают только одного подписчика (лол).


Если у тебя локальная переменная создаётся, а потом в том же методе уничтожается -- да, такого примитивного "профайлера" будет достаточно, чтобы отловить ошибки. Но как только у тебя возникают сложные ситуации, когда логика освобождения памяти нетривиальная, когда требуется считать ссылки или ещё что -- всё, труба. Потому что, узнав строчку, в которой создан неудалённый объект, ты не будешь знать, согласно какой логике в каком куске кода этот объект должен был быть удалён. Счётчик сбился? Условие не сработало? Ссылка изменилась на другой объект? Тысячи причин.


У человека возникло несколько вопросов, в таких случаях хорошая статья -- это именно то, что надо. Если нужны конкретные ответы, то там есть оглавление.

И вообще, чья бы корова мычала. Ты предлагал выковыривать код из видео семинара.  И, что показательно, так и не предоставил почтенной публике пример умного указателя в дельфи. И пула (нафантазировал какого-то монстра только, который даже не работает).


То есть в твоём понимании между объектами, выделяемыми в стеке и в куче -- огромная разница? А если вместо Foo* писать Foo&, то вообще всё разительно меняется, и объектная модель выворачивается наизнанку?  


Какие ещё "обджекты"? В нормальных языках объекты -- это экземпляры классов.

Потрясающе, теперь Атари начал повторять то, что ему изначально втолковывал.



Это как подойти к задаче, можно ведь и механизмы оповещения задействовать.



А вот это уже вторично, главное, что механизм есть. Впрочем тебе никто не мешает быть лучше меня и сэкономить человеку время на чтение.



Не изменится ничего кроме частоты ошибок. Да я понимаю, что дескать я все выдумываю, но тут я спорить не буду, потому что тебе не понять, ты видишь только то, что есть в шарпе, или в плюсах, удобства Delphi не для тебя.

@Beltar


Ты изначально вопил про один случай, я тебе изначально показывал, что существует другой. Что существует "твой" -- ОК, я не против. Но ты в "мой" до сих пор не веришь.

(И нет, если я согласился с тобой в 2 из 100 случаев, это не значит, что я проиграл спор. Как ни парадоксально.  Вот что ты игнорируешь всё, на что не можешь ответить -- это да, признание поражения.)


Ну и где код умного указателя? (И ты ещё свой "менеджер памяти" не починил.)

  

P.S. Что там у тебя в подписи? Мне лень в настройки лезть включать этот визуальный мусор.

@Beltar


В твоей модели операция удаления вершины O(NxM), операция удаления связи O(NxM). В моей -- O(NxM) и O(1), соответственно. (Оценки не учитывают ненулевую стоимость удаления из списка во всех случаях, но я бы на твоём месте на этот недочёт не упирал, потому что в твоей модели списков больше.) Разницу чувствуешь?


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

Ребят, а расскажите пожалуйста, кто какие задачи реализует по жизни? В смысле - в повседневной практике?

Всамделе не уверен я, что зацепил прям уж все приводимые примеры, но из того что запомнилось - графы, векторы, пулы объектов, отрисовка графиков..... Блин.. я этими задачами только на лабах, да курсовых мозг занимал. Не сказать чтоб я прямтаки уж очень много работ поменял, не сказать, чтоб меня из отрасли в отрасль швыряло, но пошвыривало, и таки большинство решенных мною задач - забрать набор данных, применить некое действие к объектам, отраженным в наборе: то-ли форму новую открыть, то-ли статус объекту взвести, суммы пересчитать. Среднестатистическая по сложности формула, применяемая к данным имеет алгоритимическую сложность сравнимую с расчетом НДС. Самая алгоритмически сложная из решенных мною задач за всю мою профессиональную практику мне попалась во времена, когда я работал схемотехником, потребовалось бахнуть утилиту для сравнения нетлиствов принципиальных электрических схем. Разраб херачил схему как ему удобно, в буржуйских стандартах, а девочки перерисовывали эти схемы по ЕСКД. Чтоб убедиться что один в один перерисовали - сравнивали нетлисты. И автоматизация этого процесса была архиважной, архинужной задачай, занявшей у меня без малого пару рабочих дней и таки не заставившей меня сожалеть о том, что в делфе нет ГЦ. Пожалуй эта задача в моей практике вобще уникальна в первую очередь тем, что она самая алгоритмически интересная в моей профессиональной(не любительской) практике, во вторых - она не требует взаимодействия с БД,  в третьих - не имеет как такового прикладного слоя, который хотелось бы куда-нибудь да вынести.

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

Исходя из моих реалий, меня не на столько парит трай эксепт и фри для объектов, или многокода для того, чтбы удалить ноду из графа, как парит то, что без архигеммора не удается утащить прикладную логику с датабазы, не просев при этом по юзабилити на стадии эксплуатации. Чтобы и с веб сервера, и с десктоп морды и с пакетного задания ее можно было зазюзать легко и не принужденно,  без особго парева, и чтоб на вторую линию поддержки можно было брать нормальных толковых пацанов, которым можно на пальцах объяснить как поступать если вдругчо,  а не великих амбизозных гуру, владеющих инструментами и знающих толк в извращениях ими, которые вместо того, чтоб решать проблемы и грести гoвно, станут размышлать как-оно-вобще-должно-быть-всамделе-устроено, чтоб эдакого бардака, да не былоб, на что ответ и без их рассуждений заведомо известен.

Те проблемы, которые ИРЛ стоят передо мной, не решают ни делфи, ни доднет, ни жава. Ну может питон или руби, в которых я вобще не в зуб ногой, но имею таки основания для сомнений.

А о чем вы тут гутарите - мне вобще нихера не ясно 

И вобще, равильно СергейЗР говорит: пить - вредно 

Это сообщение отредактировал(а) Zloxa - 1.5.2013, 01:02

ПСЫ: Бл#, брошу все, уйду в 1С, но жена отговаривает, говорит мне будет там скучно. Не идти же против мнения жены   

Это сообщение отредактировал(а) Zloxa - 1.5.2013, 01:09

Zloxa ты чего? Первомай уже празднуешь? А с их спора я уже только лулзы ловлю  

Это сообщение отредактировал(а) SKrivosein - 1.5.2013, 01:36