Удалить висячий указатель в C ++

Question

Удалить висячий указатель в C ++

0

После этого кода _var2 является Dangling pointer.

int* _var = new int(102);
auto _var2 = _var;
delete _var;

Должен ли я удалить _var2 (delete _var2)? Это неизбежно?

NewB 16 авг. 2014, в 09:28

Источник

1

_var2 указывает на адрес несуществующего объекта. Если кто-то может отменить ссылку на него, вы должны указать, что он указывает на действительный объект или nullptr .
juanchopanza 16 авг. 2014, в 07:27
1

_var2 и _var являются неопределенными, как только вы удалите либо . Только удалить один . (или еще лучше, используйте умные указатели )
WhozCraig 16 авг. 2014, в 07:28
0

Пример одного способа поддержания указателя параллелизм с смарт - указатели.
WhozCraig 16 авг. 2014, в 07:57

Показать ещё 1 комментарий

Теги:

c++

pointers

dangling-pointer

3 ответа

1

Я рекомендую вам использовать "std :: tr1 :: shared_ptr" для управления ресурсами.
в "эффективном c++" Скотта Мейерса в главе 3 есть полезная информация об этом.

alireza sadeghpour 16 авг. 2014, в 05:28

0

UPD. В общем случае вам не нужно это делать, потому что точки будут удалены. Если вам нужно работать с указателями, лучше установить указатель на NULL после его удаления:

int* _var = new int(102);
auto _var2 = _var;
...
if(!!_var)
{
delete _var;
_var = NULL;
}

ars 16 авг. 2014, в 05:42

1

Как сказал @Wyzard, вы вызываете delete по указателю, который указывает на некоторую память, которую нельзя deleted . Кроме того, нет необходимости для !! сравнения.
juanchopanza 16 авг. 2014, в 07:37
2

чтобы избежать подобных проблем лучше использовать std::shared_ptr
Massimo Costa 16 авг. 2014, в 07:37
0

Установка указателя на NULL после удаления звучит как ориентир начала 90-х. Сегодня я думаю, что консенсус заключается в том, что если вам нужна такая конвенция, то вы на самом деле просто скрываете реальные проблемы своего кода и дизайна.
Christian Hackl 16 авг. 2014, в 07:52
0

@ChristianHackl, все еще вполне разумно, если указатель останется в области видимости, а другой код должен иметь возможность определить, указывает ли он в данный момент на что-то или нет. Это не обязательно проблема проектирования - иметь объект, который иногда существует (размещается в куче), а иногда нет (нулевой указатель). (Конечно, это проблема дизайна - использовать для этой цели необработанный указатель вместо умного.)
Wyzard 16 авг. 2014, в 07:57
0

@ChristianHackl, не обязательно. Кто-то считает, что использование сырых указателей - это «грязный» способ программирования в современном мире. Но я думаю, лучше понять, как это работает «под капотом».
ars 16 авг. 2014, в 07:57
0

@Wyzard: Для потока управления, который на самом деле спроектирован так с нуля, иногда все в порядке, и я сам использовал этот шаблон. Но руководство часто используется как своего рода механизм проверки ошибок или предотвращения ошибок, в соответствии с тем, что «если какой-то другой фрагмент кода впоследствии случайно снова удалит указатель, программа может завершиться сбоем, поэтому лучше установить ее в значение NULL. прочь, чтобы программа не вылетала ". Это IMO означает молча принимать ошибочные состояния программы и скрывать ошибки.
Christian Hackl 16 авг. 2014, в 08:03

Показать ещё 4 комментария

Ещё вопросы

_var2 указывает на адрес несуществующего объекта. Если кто-то может отменить ссылку на него, вы должны указать, что он указывает на действительный объект или nullptr .
_var2 и _var являются неопределенными, как только вы удалите либо . Только удалить один . (или еще лучше, используйте умные указатели )
Пример одного способа поддержания указателя параллелизм с смарт - указатели.
Как сказал @Wyzard, вы вызываете delete по указателю, который указывает на некоторую память, которую нельзя deleted . Кроме того, нет необходимости для !! сравнения.
чтобы избежать подобных проблем лучше использовать std::shared_ptr
Установка указателя на NULL после удаления звучит как ориентир начала 90-х. Сегодня я думаю, что консенсус заключается в том, что если вам нужна такая конвенция, то вы на самом деле просто скрываете реальные проблемы своего кода и дизайна.
@ChristianHackl, все еще вполне разумно, если указатель останется в области видимости, а другой код должен иметь возможность определить, указывает ли он в данный момент на что-то или нет. Это не обязательно проблема проектирования - иметь объект, который иногда существует (размещается в куче), а иногда нет (нулевой указатель). (Конечно, это проблема дизайна - использовать для этой цели необработанный указатель вместо умного.)
@ChristianHackl, не обязательно. Кто-то считает, что использование сырых указателей - это «грязный» способ программирования в современном мире. Но я думаю, лучше понять, как это работает «под капотом».
@Wyzard: Для потока управления, который на самом деле спроектирован так с нуля, иногда все в порядке, и я сам использовал этот шаблон. Но руководство часто используется как своего рода механизм проверки ошибок или предотвращения ошибок, в соответствии с тем, что «если какой-то другой фрагмент кода впоследствии случайно снова удалит указатель, программа может завершиться сбоем, поэтому лучше установить ее в значение NULL. прочь, чтобы программа не вылетала ". Это IMO означает молча принимать ошибочные состояния программы и скрывать ошибки.

Wyzard · Accepted Answer · 2014-08-16T05-24-00.000Z

Нет, потому что он уже удален.

delete ключевых слов на самом деле не удалить указатель, он удаляет значение, которое он указывает. В этом случае вы выделяете целое число 102 в куче в строке 1, а затем вы удаляете это целое число в строке 3. Оба ваших указателя (_var и _var2) по-прежнему содержат адрес, где было целое число, но его больше нет. delete _var2 будет неправильным, потому что на этом адресе ничего не выделяется.

Я подозреваю, что OP может думать, что ключевое слово delete C ++ работает аналогично оператору delete JavaScript.
Интересно, как бы проще было бы жить миллионам начинающих C ++, если бы ключевое слово было названо что-то вроде delete_at ... :)
@Wyzard Я новичок в C ++, но я не думаю, что это правильно. Значение, которое было в ячейке памяти, может все еще быть там, или может не быть. Все, что нужно сделать, - это сделать этот адрес памяти доступным для других указателей, созданных с помощью нового оператора.
@pyetti, как деталь реализации, вы правы (по крайней мере, для типичных компьютеров), но что касается языка C ++, после delete больше нет int в месте, на которое указывает указатель. Неважно, какие значения могут остаться в нижележащих байтах в ОЗУ, потому что вам не разрешено разыменовывать указатель, чтобы увидеть их. Это как при удалении файла на вашем компьютере: содержимое может остаться в секторах на жестком диске, но там больше нет файла , и вы не можете удалить файл во второй раз, потому что он уже удален.