Тут недавно обнаружил что в проекте давольно успешно работал уже удалённый обьект. Причём с виртуальными функциями и обращением к мемберам. Вопрос такой. В какие обычно значения скидывают скажем указатели в деструкторе, дабы потом при обращении к ним возник AV. 0 — не предлагать

Здравствуйте, Tom, Вы писали:

Tom>Тут недавно обнаружил что в проекте давольно успешно работал уже удалённый обьект. Причём с виртуальными функциями и обращением к мемберам. Вопрос такой. В какие обычно значения скидывают скажем указатели в деструкторе, дабы потом при обращении к ним возник AV. 0 — не предлагать
-1

Ненадо ничего скидывать — от лукавого это. ИМХО надо избавляться в проекте от "голых" указателей и вводить их под управлением smart pointer-ов.

Здравствуйте, Tom, Вы писали:

Tom>Тут недавно обнаружил что в проекте давольно успешно работал уже удалённый обьект. Причём с виртуальными функциями и обращением к мемберам. Вопрос такой. В какие обычно значения скидывают скажем указатели в деструкторе, дабы потом при обращении к ним возник AV. 0 — не предлагать

По идее правильно бы было если бы скидывал хипменеджер.

Но скидывание может и не помочь, просто по причине реалокации памяти под другой обьект. Мы боролись тестированием с собственной реализацией хипа. Жёсткий чек целостности и стратегия, при которой память как можно дольше не реалакируется, в принципе достаточно хорошо отлавливают подобные ошибки. Не гарантированно конечно. Гарантии тут, ИМХО, вообще не возможны. И никакие умные указатели не спасут.

АШ>Ненадо ничего скидывать — от лукавого это. ИМХО надо избавляться в проекте от "голых" указателей и вводить их под управлением smart pointer-ов.

Данное утверждение эквиавлентно "выбросьте проект и перепишите его по-новой". А надо всего лишь поправить ошибку. Это во-первых.

Во-вторых, смарт-поинтеры нужны лишь для реализации некой пародии на сборку мусора методом подсчета ссылок. Если же в данном проекте стратегия с типа-автоматической сборкой мусора не заложена в изначальном дизайне, то они и не нужны. Максимум, что нужно — это auto_ptr и то очень-очень редко. А использовать надо контейнеры — стандартные или свои, не важно. Главное что контейнеры, самоудаляющиеся.

Здравствуйте, Tom, Вы писали:

Tom>Тут недавно обнаружил что в проекте давольно успешно работал уже удалённый обьект. Причём с виртуальными функциями и обращением к мемберам. Вопрос такой. В какие обычно значения скидывают скажем указатели в деструкторе, дабы потом при обращении к ним возник AV. 0 — не предлагать

Существют такие средства, как BoundsChecker и CodeGuard. Рекомендую.

Здравствуйте, Tom, Вы писали:

Tom>Тут недавно обнаружил что в проекте давольно успешно работал уже удалённый обьект. Причём с виртуальными функциями и обращением к мемберам. Вопрос такой. В какие обычно значения скидывают скажем указатели в деструкторе, дабы потом при обращении к ним возник AV. 0 — не предлагать

Имхо, затраты времени и сил на написание такого кода:

~some_object_t()
    {
        delete some_ptr_;
        some_ptr_ = MAGIC_NULL_VALUE;
        
        delete another_ptr_;
        another_ptr_ = MAGIC_NULL_VALUE;
        ...
    }

вполне сравнимы с тем, чтобы:
— просто проверить соответствие new/delete;
— перейти на использование std::auto_ptr (или других умных указателей), или использовать std::vector вместо new something[];
— найти таки причину "повисания" указателя на уже удаленный объект.

Кроме того, с магическими числами еще и будет выполнятся лишняя работа -- сброс указателей после delete. И это при том, что в 99% случаев это совершенно не требуется. А оставшийся 1% -- это ошибки, которые по любому нужно найти и исправить.

Здравствуйте, Tom, Вы писали:

Tom>Тут недавно обнаружил что в проекте давольно успешно работал уже удалённый обьект. Причём с виртуальными функциями и обращением к мемберам. Вопрос такой. В какие обычно значения скидывают скажем указатели в деструкторе, дабы потом при обращении к ним возник AV. 0 — не предлагать

Мертвая говядина

Автор: ansi
Дата: 05.07.05