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

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

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

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

0

Есть "умные" указатели например std::shared_ptr<> остается только научится им пользоваться.

К книге Шилда был пример реализации однопоточного сборщика мусора.

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

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

Да - просто не писать код с такими ошибками.

1

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

Никак. Если вылезла такая хотелка, то это однозначный признак кривого планирования. Такое бывает и лечится выкидыванием говнокода в помойку и написанием нового годного кода.

0

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

std::weak_ptr знает удалён объект, на который он указывает или нет. Работает только в паре с std::shared_ptr.

1

Avazart, oleg-m1973, Verevkin,
спасибо за ответы.
Вопрос(в поднятой теме) более серьезный, чем рекомендации: "писать хороший код, а не плохой"

Стоит сложная задача, специально не сообщаю о деталях, а акцентируюсь на проблеме: Нужны такие "Указатели", которые бы умели определять, что Объект(на который ссылаются) уже был удален.
Вроде простая задача?!

К сожалению, стандартные shared_ptr и weak_ptr хоть и походят по функционалу, НО, имеют серьезные недостатки:
- Занимают много места (под каждый указатель выделяют сложный объект)
- Медленно работают (подсчитывают ссылки, обеспечивают многопоточность, ...)

В моей задаче требуется скорость и компактность, поэтому придется изобретать “велосипед”, м.б. придумать менеджер указателей, и под “указателем” сделать Index в массиве, или ID в списке, или к-л другую структуру.

Подскажите идеи?

Сообщение от Avazart К книге Шилда был пример реализации однопоточного сборщика мусора.

Смотрю 4-е издание Г.Шилдт “C++. Полный справочник", но не могут найти пример. Слова “garbage” и “мусор” встречаются всего 7 раз, но примера не видно.

0

Сообщение от Artem_Pv К сожалению, стандартные shared_ptr и weak_ptr хоть и походят по функционалу, НО, имеют серьезные недостатки:

Это не их недостатки, это недостатки твоего образования (я правильно понимаю, что программировать ты учился на си-шарпе?). Ничего лучше shared_ptr/weak_ptr ты здесь не придумаешь. Достаточно просто научиться их использовать.

Сообщение от Artem_Pv В моей задаче требуется скорость и компактность,

Задача-то какая?

0

Если не ошибаюсь книга называлась "Искусство программирования ..." или как то так.

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

Сообщение от Artem_Pv В моей задаче требуется скорость и компактность, поэтому придется изобретать “велосипед”, м.б. придумать менеджер указателей, и под “указателем” сделать Index в массиве, или ID в списке, или к-л другую структуру.

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

1

Сообщение от Artem_Pv Смотрю 4-е издание Г.Шилдт “C++. Полный справочник", но не могут найти пример. Слова “garbage” и “мусор” встречаются всего 7 раз, но примера не видно.

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

0

Сообщение от Artem_Pv Смотрю 4-е издание Г.Шилдт “C++. Полный справочник", но не могут найти пример. Слова “garbage” и “мусор” встречаются всего 7 раз, но примера не видно.

Герберт Шилдт - Искусство программирования на С++

1

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

Не под каждый указатель, а под каждый объект (хранимый).

Сообщение от Artem_Pv поэтому придется изобретать “велосипед”, м.б. придумать менеджер указателей, и под “указателем” сделать Index в массиве, или ID в списке, или к-л другую структуру.

Это полная ерунда и будет медленнее, чем даже решение в лоб через shared_ptr.

В С++ нафиг это все не надо. И shared_ptr в том числе в единицах случаев действительно нужен. unique_ptr в большинстве случаев достаточно.

Если у тебя образуются висячие указатели, значит ты фигово применяешь инструмент (С++), не разобрался в методологии (RAII), придумал плохую архитектуру и т.д. Это даже не мое мнение, а просто факт, иначе бы С++ не был таким, какой он есть, а был бы похож на С# или подобные. И чтобы ты не говорил мне в ответ на это - реальность не изменится и единственный способ выйти из порочного круга - это повышать свое образование, а не пытаться натягивать сову на глобус.

1

Сообщение от ablex shared_ptr.

Не такой уж тяжелый объект, там указатель и счетчик по сути. Учитывая что сам объект который хранится по указателю более тяжелый - это копейки.

Если же объект легкий то стоит вообще не удалять объекты, а использовать их из пула объектов.

В любом случае все зависит от конкретных условий.

0

Avazart, я нигде не писал, что он тяжелый.

0

Сообщение от Avazart Герберт Шилдт - Искусство программирования на С++

Avazart, спасибо за ответ.
Пример в книге найден, но, к сожалению, не походит для моей задачи, т.к. подсчет ссылок НЕ требуется, и как выше писалось, это слишком ресурсоемко. Аналогичная проблема с shared_ptr, ... да, он решает мою задачу, но реализован слишком “круто”, и требует много ресурсов и это критично.

Чтоб стало ясно, я тестирую реальный пример:
В задаче задействовано (внимание)100 млн. “указателей” на разные объекты(их около 1 млн.). Причем обычные (32 bit)указатели работают быстро и компактно. Программа летает и все хорошо, НО, эти указатели не умеют отслеживать удаление объектов (они становятся “висячими указателями”).
Поэтому ищется оптимальная замена.
Просто заменить обычные указатели на shared_ptr - на таких количествах НЕ удается. Экспериментальным путем находим пределы, где программа перестает зависать и расходовать всю память. Пришлось уменьшить кол-во shared_ptr на много порядков меньше, чем требуется (см. цифру выше). И это только чтоб запустить программу. Но, мучения на этом НЕ заканчиваются, т.к. удаления объектов(на которые ссылаются shared_ptr) превращается в дикие тормоза.

Никто не спорит, что shared_ptr - хороший, удобный указатель; НО, в моей задаче он слишком ресурсоемкий (по сравнению с обычным указателем), к сожалению, не подходит для, казалось бы, простой вещи:
“Если объект удаляется, то указатели на него обнуляются”.
Неужели сложно придумать решение?!

0

Artem_Pv,

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

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

1

Сообщение от Artem_Pv Неужели сложно придумать решение?!

Ты как врач, который лечит симптомы, вместо лечения причин. У таких врачей пациенты умирают. Вот и вся правда.
Без затрат ресурсов отследить владеет ли указатель все еще объектом или объект уже сдох - невозможно. Именно поэтому С++ не предлагает ничего подобного по умолчанию.
В твоей ситуации единственный вариант - это не допускать висячих указателей вообще - переписать этот проблемный код нормально: только хирургия, никаких припарок.

0

Сообщение от Artem_Pv т.к. подсчет ссылок НЕ требуется,

А что требуется тогда? Как Вы предлагаете определять объекты которые не используются?

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

Сообщение от Artem_Pv к сожалению, не подходит для, казалось бы, простой вещи: “Если объект удаляется, то указатели на него обнуляются”.

И как по Вашему объект должен знать о всех указателях на него? Путем телепатии?

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

Сообщение от Artem_Pv Неужели сложно придумать решение?!

Вы страдаете фигней.

0

"Висячие указатели" - это НЕ проблема, они никак НЕ мешают, и НЕ беспокоят, я просто указал этот термин, чтоб было понятно, о чем речь.

Ух, еще раз попробую акцентировать внимание на суть темы.
Для очень серьезной/уникальной задачи(OLAP-куб), ищется методика: Научить объекты чистить за собой указатели.

Сообщение от Avazart И как по Вашему объект должен знать о всех указателях на него?

Так это есть вопрос темы.
Ведь, shared_ptr как-то знает об указателях? Да знает.
А как он это делает, есть идеи?

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

DrOffset, спасибо за ответ.

Я ищу методику(идею).
Например:
- под "указателем" подразумевать структуру/обертку вокруг обычного указателя
- объекты создаются/удаляются строго через специальный менеджер, который также следит за указателями
- и т.д...

Ведь в основе "shared_ptr" тоже лежит какая-то идея, и чтоб методика заработала, где-то в глубине они хранят структуры под каждый указатель и следят за уничтожением объектов. Или как-то по-другому. Вот как?

0

Сообщение от Artem_Pv Ведь, shared_ptr как-то знает об указателях? Да знает. А как он это делает, есть идеи?

В смысле - идеи? Это документировано, никаких идей не надо.

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

1

Сообщение от Artem_Pv Ведь, shared_ptr как-то знает об указателях? Да знает. А как он это делает, есть идеи?

Не знает, он просто знает об общем счетчике.
Можно конечно и все объекты помнить он это куда накладнее.

0

Сообщение от ablex Ты как врач, который лечит симптомы, вместо лечения причин.

Пациент приходит к врачу с разбитой головой, жалуется, что на улице упал кирпич на голову. Врач со словами “я лечу причину” и идет на улицу и прячет кирпич, что больше не падал. Жаль пациента, так и сидит с разбитой головой.
;-/

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

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

Сообщение от DrOffset структура с счетчиком ссылок

А зачем вообще здесь счетчик ссылок? Ведь, чтоб их обнулять нужно знать сами ссылки(а не их количество).

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

0