Здравствуйте, знатоки.
Писал приложение, активно использующее указатели. Чтобы облегчить себе работу по освобождению памяти, решил заодно в программу сборщик мусора включить. Посмотрел книжки по этому делу. Выбрал алгоритм (подсчет ссылок). Попробовал реализовать. Реализация падала при очистке памяти. Решил содрать код из книжки. ТО ЖЕ САМОЕ!!!!!! и в том же месте.
Вот код сборки мусора, из книжки:

Попробовал выяснить, откуда такое значение берется. Насколько я разобрался, функция void remove(const _Ty& _Val_arg) из list вызывает функцию iterator erase(const_iterator _Where) оттуда же вот так:


И здесь возвращается значение memPtr=0xfeefee вот отсюда:

В общем вопросов много: что значит такое значение указателя? почему оно возникает? как с этим бороться? как это обойти в данной ситуации?
Помогите советом. Заранее спасибо.
ps только не надо спрашивать ЗАЧЕМ

Это сообщение отредактировал(а) gleb1310 - 1.7.2010, 10:46

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

И так понятно откуда - как попросили уделить элемент из списка (gclist.remove(*p);), так список его и удалил. Попутно разрушил и содержимое элемента (позвал ему деструктор и вернул память в кучу). Так что делать p->memPtr ПОСЛЕ gclist.remove явно незаконно

gleb1310, особо не вникала, но вроде бы так: ты удаляешь элемент списка, и итератор становится невалидным, а потом пытаешься им же воспользоваться. Поменяй местами remove и  скобку if(p->memPtr).
И еще, нафига удалять из списка значение, если у тебя есть итератор? Можно сразу писать erase. 
И можно написать все в рамках простого цикла, без выкрутасов:

А 0xfeeefeee -это вариант "дохлой коровы" от Майкрософт - так они в дебаге освобожденные указатели помечают.
А в некоторых других компиляторах это действительно deedbeef

там дальше тоже используется p->memPtr. не получится.
Дело в том, что это код из книги Герберта Шилдта "Искусство программирования на С++". В вопросе я конечно не весь код написал. вроде бы в нем все должно быть правильно. Но он не работает. Вот я и хочу понять почему.

Тебе же сказали - потому что код неправильный. Что, у Шилдта действительно stl::list использовался, или это ты "творчески переосмыслил"? Или, может, ты думаешь, что в книгах косяков не бывает?

Да, использовался. Именно так все и реализовано у него.
Его сборщик состоит из шаблонного класса GCPtr - указатель, предназначенный для сбора мусора, поддерживающий список, который связывает счетчик ссылок с каждым фрагментом памяти, выделенным с помощью GCPtr; класса GCInfo - элементы списка из класса GCPtr; Iter - шаблонный класс (== iterator из STL + контроль границ).

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

Да. И в первую очередь - сам p

Что это значит? а если элемент не последний? Если удалить сам итератор, то как перейти на следующий элемент? 

Замечательный вопрос! А сами как думаете?   

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

Посмотрите пожалуйста код, может что неправильно:
 

Переменная tmp_memPtr не описана, да и вообще не нужна:

xvr:


Что значит не описана????


xvr:

В ТОМ ТО И ВОПРОС!!!!!!!! Без нее НИКАК память не очистить! Прочитайте первый пост. После удаления элемента из списка указатель p->memPtr становится равным 0xfeefee и обратиться по нему к занятой памяти НЕВОЗМОЖНО!