В книге на C ++, которую я читал, говорится, что когда указатель удаляется с помощью deleteоператора, память в том месте, на которое он указывает, «освобождается» и может быть перезаписана. В нем также указано, что указатель будет продолжать указывать на то же место, пока он не будет переназначен или установлен на NULL.

Однако в Visual Studio 2012; похоже, что это не так!

Пример:

#include <iostream>

using namespace std;

int main()
{
    int* ptr = new int;
    cout << "ptr = " << ptr << endl;
    delete ptr;
    cout << "ptr = " << ptr << endl;

    system("pause");

    return 0;
}

Когда я компилирую и запускаю эту программу, я получаю следующий результат:

ptr = 0050BC10
ptr = 00008123
Press any key to continue....

Очевидно, что адрес, на который указывает указатель, изменяется при вызове удаления!

Почему это происходит? Связано ли это конкретно с Visual Studio?

И если delete в любом случае может изменить адрес, на который он указывает, почему бы delete автоматически не установить указатель NULLвместо некоторого случайного адреса?

Я заметил, что адрес, хранящийся в, ptrвсегда перезаписывался 00008123...

Это казалось странным, поэтому я немного покопался и нашел это сообщение в блоге Microsoft, содержащее раздел, посвященный «Автоматическая очистка указателя при удалении объектов C ++».

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

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

Он не только объясняет, что Visual Studio делает с указателем после его удаления, но и объясняет, почему они решили НЕ устанавливать его NULLавтоматически!

Эта «функция» включена как часть настройки «Проверки SDL». Чтобы включить / отключить его, перейдите в: ПРОЕКТ -> Свойства -> Свойства конфигурации -> C / C ++ -> Общие -> Проверки SDL

Чтобы подтвердить это:

Изменение этого параметра и повторный запуск того же кода дает следующий результат:

ptr = 007CBC10
ptr = 007CBC10

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

ОБНОВИТЬ:

Проработав еще 5 лет в программировании на C ++, я понял, что вся эта проблема в основном спорный. Если вы программист на C ++ и все еще используете newи deleteуправляете необработанными указателями вместо использования интеллектуальных указателей (которые позволяют обойти всю эту проблему), вы можете подумать об изменении карьеры, чтобы стать программистом на C. ;)

Вы видите побочные эффекты /sdlопции компиляции. Включенный по умолчанию для проектов VS2015, он позволяет выполнять дополнительные проверки безопасности помимо тех, которые предоставляет / gs. Используйте «Проект»> «Свойства»> «C / C ++»> «Общие»> «Проверки SDL», чтобы изменить его.

Цитата из статьи MSDN :

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

Имейте в виду, что установка удаленных указателей на NULL - плохая практика при использовании MSVC. Это сводит на нет помощь, которую вы получаете как от Debug Heap, так и от этого параметра / sdl, вы больше не можете обнаруживать недопустимые вызовы free / delete в своей программе.

В нем также указано, что указатель будет продолжать указывать на то же место, пока он не будет переназначен или не будет установлен в NULL.

Это определенно вводящая в заблуждение информация.

Очевидно, что адрес, на который указывает указатель, изменяется при вызове удаления!

Почему это происходит? Связано ли это конкретно с Visual Studio?

Это явно находится в пределах языковых спецификаций. ptrнедействителен после вызова delete. Использование ptrпосле того, как это было deleted, является причиной неопределенного поведения. Не делай этого. Среда выполнения может делать все, что захочет, ptrпосле вызова delete.

И если delete все равно может изменить адрес, на который он указывает, почему бы delete автоматически не установить указатель на NULL вместо некоторого случайного адреса ???

Изменение значения указателя на любое старое значение находится в пределах спецификации языка. Что касается изменения его на NULL, я бы сказал, что это было бы плохо. Программа вела бы себя более разумно, если бы значение указателя было установлено в NULL. Однако это скроет проблему. Когда программа скомпилирована с другими настройками оптимизации или перенесена в другую среду, проблема, скорее всего, проявится в самый неподходящий момент.

delete ptr;
cout << "ptr = " << ptr << endl;

В общем, даже чтение (как вы это делаете выше, обратите внимание: это отличается от разыменования) значений недопустимых указателей (указатель становится недействительным, например, когда вы deleteэто делаете ) является поведением, определяемым реализацией. Это было представлено в CWG № 1438 . Смотрите также здесь .

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

Я считаю, что вы используете какой-то режим отладки, и VS пытается перенаправить ваш указатель на какое-то известное место, чтобы можно было отследить дальнейшую попытку разыменования и сообщить о нем. Попробуйте скомпилировать / запустить ту же программу в режиме выпуска.

Указатели внутри обычно не меняются delete ради эффективности и во избежание ложного представления о безопасности. Установка указателя удаления на предопределенное значение не принесет пользы в большинстве сложных сценариев, поскольку удаляемый указатель, вероятно, будет только одним из нескольких, указывающих на это место.

На самом деле, чем больше я думаю об этом, тем больше я нахожу, что VS, как обычно, виноват в этом. Что делать, если указатель постоянный? Это все еще изменит это?

После удаления указателя память, на которую он указывает, может оставаться действительной. Чтобы проявить эту ошибку, значение указателя устанавливается на очевидное значение. Это действительно помогает процессу отладки. Если значение было установлено NULL, оно может никогда не проявиться как потенциальная ошибка в потоке программы. Таким образом, он может скрыть ошибку, когда вы позже протестируете ее NULL.

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

В прежние времена MS устанавливала значение на 0xcfffffff.