Как “научить” Указатель определять, что сам Объект уже удален?

Кажется, это называется “Висячий Указатель”, который указывает на уже удаленный Объект.
Хочется, чтоб когда Объект удаляется из памяти, то все указатели на него обращались бы NULL. Как это сделать?

М.б. существуют какие-то методики, чтобы бороться с Висячими Указателями?

Я уже отчаялся и пытаюсь придумать свой “велосипед” : типа менеджер Объектов, который регистрирует указатели и следит за удаляемыми объектами.
Но, надеюсь, что есть более простые способы.
Пожалуйста, подскажите...

0

Сообщение от Artem_Pv серьезная задача

Безотносительно темы. Ты серьезно считаешь, что форум - это подходящий способ решать такие задачи? Кто потом будет отвечать за это решение?
Допустим даже я сейчас тебе накидаю пример, кто за последствия его применения будет в ответе, я или ты? Я тебе гарантий никаких не дам. Если уж у тебя не хватает квалификации выработать это решение самостоятельно, то лучше будет привлечь кого-то, кто даст эти гарантии. Это если задача и правда серьезная, а не ты ее такой хочешь представить. Просить "бесплатных" советов на форуме для серьезных задач - это чистая и незамутненная форма профанации.

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

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

Вот и что?

Поэтому общий ответ в силе: лечить надо причину.

0

Сообщение от Artem_Pv Еще жаль, что серьезная задача(OLAP-куб) обернулась в офф-топик.

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

0

Сообщение от Artem_Pv А зачем вообще здесь счетчик ссылок?

В смысле - "здесь"?
Я рассказал как устроен shared_ptr в ответ на этот вопрос.

Сообщение от Artem_Pv А как он это делает, есть идеи?

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

1

Artem_Pv, таки используй std::shared_prt , но в объект ещё добавь флажок deleted. Перед "удалением" из своего контейнера выставляй этот флажок. Если где-то есть указатели, они всегда смогут понять, что объект "удалён" и сами указатели можно почистить

0

Сообщение от Artem_Pv Речь идет про динамический объект: 1. создаем Объект 2. присваиваем N указателей на Объект 3. удаляем Объект 4. (внимание)здесь нужно, чтоб эти N указателей обнулились

1) Общий на всю программу пул объектов.
2) Выделение и владение (это важно) происходит только в этом пуле, владеющий указатель сохраняется в спец. ячейку.
3) Наружу отдаются обертки с указателем на ячейку в пуле.
4) Всегда можно обратиться к ячейке в пуле и проверить жив объект или нет. Если пул сам обнулит ячейку, но она обнулится у всех ссылающихся на нее указателей.

Проблемы:
1) ячейка в пуле может быть перезанята, и проверка сломается;
2) можно не использовать ячейки повторно, или использовать их только по истечении какого-то времени (со всеми вытекающими из этого недостатками по расходу памяти);
3) сама ячейка всегда должна быть доступна для чтения, иначе вернемся к исходной проблеме.

1

Сообщение от Алексей1153 Artem_Pv, таки используй std::shared_prt , но в объект ещё добавь флажок deleted. Перед "удалением" из своего контейнера выставляй этот флажок. Если где-то есть указатели, они всегда смогут понять, что объект "удалён" и сами указатели можно почистить

Бред.
std::shared_ptr освобождает память только если счетчик становится = 0, иначе просто ничего не делает кроме уменьшения счетчика.

Добавлено через 6 минут
DrOffset, Ну это по сути тоже что и gc писать или использовать пару shared+weak

0

Сообщение от Avazart Ну это по сути тоже что и gc писать

В целом да.

0

Сообщение от DrOffset Проблемы: 1,2,3) ...

думаю, что не-проблема:
Когда требуется повторно использовать ячейки(уже удаленных объектов), то запускается процедура Упаковки всего пула, где перестраиваются внешние указатели на оставшиеся ячейки в пуле.

0

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

0

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

Иначе просто никак...

0

Сообщение от Avazart придется указатели заменить объектами собственного класса(указателе-подобными)

Обертка вокруг указателя - это м.б. объект, но лучше какая-нибудь легкая структура для оптимальности, главное, чтоб ее понимал менеджер пула объектов.

Сообщение от Avazart будут как говорит ТС "тяжелыми" ...

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

0

Сообщение от Artem_Pv - Занимают много места (под каждый указатель выделяют сложный объект) - Медленно работают (подсчитывают ссылки, обеспечивают многопоточность, ...)

Сообщение от Artem_Pv 100 млн. “указателей”

Сообщение от Artem_Pv указатели работают быстро и компактно. Программа летает и все хорошо

это примерно 762.94 mb
тут два варианта: либо на машине реально есть столько памяти,
либо нет, и тогда узким горлышком будет файл подкачки.

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

смарт-поинтер сам по себе узким горлышком не бывает.

0

Сообщение от Artem_Pv но лучше какая-нибудь легкая структура для оптимальности

Чем Вам shared_ptr не легкая структура?

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

Сообщение от Artem_Pv ТС обнаружил, что "тяжелый" именно shared_prt, т.к. делает много лишней работы: подсчет ссылок, управление многопоточностью, т.е. это конечно полезно в других задачах, но не для текущей.

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

0

Сообщение от Avazart В любом случае придется указатели заменить объектами собственного класса(указателе-подобными)

...

Сообщение от DrOffset Наружу отдаются обертки с указателем на ячейку в пуле.

...

0

DrOffset, Акцент был на

Сообщение от Avazart которые будут как говорит ТС "тяжелыми" ...

0

Artem_Pv, Объект помнит эти n указателей в списке и из своего деструктора их обнуляет. Указатели соответсвенно добавляются/удаляются из оного списка в своих конструкторах/операторах присваивания/деструкторахю Возможна реализация на основе односвязного списка с хранением указателя в самом смарте, как это сделано в итераторах STL. Так же и вариация на тему двусвязного списка с O(1) удалением смарта-подписчика.
В общем обширный список способов под общим названием "двунаправленные указатели". Если капать глубже - то одно из возможных реализаций/применений паттерна "обсервер".

1

Сообщение от Fulcrum_013 Объект помнит эти n указателей в списке и из своего деструктора их обнуляет.

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

0

это, получается, придётся хранить список указателей на указатели, ваще огонь И ни разу не оверхед. И просто то как!

0

Сообщение от Artem_Pv Не нужно использовать управляющий движок(менеджер объектов).

Кстати если не нужно инстантное оповещение и/или нужно чтобы он никуда не делся пока его обрабатывают можно сделать на контроллерах на подобин shared/weak только с немного другим механизмом - т.е. удаляется объект не тогда когда счетчик жестких ссылок достиг нуля, а тогда когда он достиг нуля и флаг удалить поднят. Смарт реализующий композицию взводит флаг в своем деструкторе. Контроллер удаляется когда счетчик контроллеров достиг нуля. Смарт указывающий на пустой контроллер при локе сбрасывает и указатель на контроллер. Удаление же производится поднятием флага. При использовании двух видов смартов - аггрегация и композиция вполне работоспособно и для объектов не знающих о самой системе. Для таких правда нельзя организовать самоудаление - для этого объект должен знать контроллер и сам взводить флаг в контроллере, а не только смарт реализующий композицию.

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

Сообщение от Алексей1153 это, получается, придётся хранить список указателей на указатели, ваще огонь И ни разу не оверхед. И просто то как!

ОВерхед будет в любом случае. Другой только вопрос по памяти (от 2x до 3х по размеру указателей для инстантного оповещения - что в общемто мелочи) и однократный по производительности при оповещении, или поcтоянно по прозизводительности на локи при каждом разыменовывании, и слегка меньший по памяти на хранение контроллеров, что гораздо гораздо менее приятно.
При этом список в принципе может быть односвязный и хранится указатель на следующего в самом смарте. С контроллерами все равно придется зранить два указателя - на объект и на контроллер.

Добавлено через 10 минут
Все в конечном итоге зависит от паттерна добавоения / удаления самтх указателей и того где более приемлем оверхед - по памяти или по производительности. К примеру у итераторов добавление/удаление в список производится строго в порядке первым добавлен/последни удален, а долгоживущих которые этим правилам не подчиняются или вообще нет или их мизер. Здесь оверхед на O(n) поиск в односвязном списке по производительности будет либо мизерным либо его вообще не будет, и соответсвенно можно слегка поэкономить память на второй связности списка. А если паттерн произвольный - то оверхед уже будет гораздо более значительный и гораздо логичнее добавить третий указатель на предыдущего в итератор, но получить удаление итератора из списка за O(1).

1

Сообщение от Алексей1153 это, получается, придётся хранить список указателей на указатели, ваще огонь И ни разу не оверхед. И просто то как!

Я про это и говорил это куда "тяжелее" умного указателя получаться в котором только указатель на счетчик хранится.

0