Книга 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 може змінити адресу, на яку він вказує, будь-коли, чому б не видалити автоматично встановити покажчик NULLзамість якоїсь випадкової адреси?

Я помітив, що адреса, що зберігається, ptrзавжди перезаписується 00008123...

Це здалося дивним, тому я трохи прокопав і знайшов цю публікацію в блозі Microsoft, що містить розділ, в якому обговорювалося "Автоматизована санітарія покажчика при видаленні об'єктів C ++".

... перевірки на NULL - це звичайна конструкція коду, що означає, що наявна перевірка NULL у поєднанні з використанням NULL як значення санітарії може випадково приховати справжню проблему безпеки пам’яті, корінна причина якої справді потребує вирішення.

З цієї причини ми вибрали значення 0x8123 як санітарне значення - з точки зору операційної системи це перебуває на тій же сторінці пам'яті, що і нульова адреса (NULL), але порушення доступу в 0x8123 краще виділить розробника як потребує більш детальної уваги .

Він не тільки пояснює, що робить Visual Studio з покажчиком після його видалення, але також відповідає, чому вони вибрали НЕ, щоб встановити його NULLавтоматично!

Ця "функція" увімкнена в рамках налаштування "Перевірки SDL". Щоб увімкнути / відключити його, перейдіть до: PROJECT -> Properties -> Properties (Властивості конфігурації) -> C / C ++ -> General -> SDL перевірки

Щоб підтвердити це:

Зміна цього параметра та повторний повтор одного і того ж коду дає такий результат:

ptr = 007CBC10
ptr = 007CBC10

"особливість" міститься в лапках, оскільки у випадку, коли у вас є два вказівники на одне місце, виклик видалення лише оздоровить ОДИН з них. Інший залишиться вказувати на недійсне місце ...

ОНОВЛЕННЯ:

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

Ви бачите побічні ефекти параметра /sdlкомпіляції. Увімкнено за замовчуванням для проектів VS2015, він забезпечує додаткові перевірки безпеки, ніж ті, що надаються / gs. Використовуйте Project> Properties> C / C ++> General> SDL перевіряє налаштування, щоб змінити його.

Цитуючи статті MSDN :

• Здійснює обмежену санітарію вказівника. У виразах, які не включають перенаправлення, та у типах, що не мають визначеного користувачем деструктора, посилання вказівника встановлюються на недійсну адресу після виклику для видалення. Це допомагає запобігти повторному використанню застарілих посилань на вказівник.

Майте на увазі, що встановлення видалених покажчиків на NULL є поганою практикою, коли ви використовуєте MSVC. Він перемагає допомогу, яку ви отримуєте як від налагодження Heap, так і з цього параметра / sdl, ви більше не можете виявляти недійсні безкоштовні / видалення викликів у вашій програмі.

Він також повідомляє, що покажчик продовжуватиме вказувати на те саме місце, поки він не буде призначений або встановлений на NULL.

Це однозначно оманлива інформація.

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

Чому це відбувається? Чи має це щось спільне з Visual Studio?

Це явно в мовних специфікаціях. ptrнедійсний після дзвінка на delete. Використання ptrпісля його deleted є причиною для невизначеної поведінки. Не робіть цього. Середовище виконання часу вільне робити все, що хоче, ptrпісля дзвінка delete.

І якщо delete може змінити адресу, на яку він вказує, будь-коли, чому б не видалити автоматично встановити вказівник на NULL замість якоїсь випадкової адреси ???

Зміна значення вказівника на будь-яке старе значення відбувається в межах мовної специфікації. Що стосується зміни його на NULL, я б сказав, це було б погано. Програма поводилася б більш розумно, якби значення вказівника було встановлено на NULL. Однак це приховає проблему. Коли програма компілюється з різними налаштуваннями оптимізації або переноситься в інше середовище, проблема, ймовірно, виявиться в самий невідповідний момент.

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

Загалом, навіть при читанні (як ви робите вище) зауважте: це відрізняється від перенаправлення значень недійсних покажчиків (вказівник стає недійсним, наприклад, коли ви deleteце) - це визначена реалізацією поведінка. Це було внесено в CWG № 1438 . Дивіться також тут .

Зауважте, що до цього значення читання недійсних покажчиків було невизначеною поведінкою, тому те, що у вас є вище, було б невизначеною поведінкою, що означає, що все може статися.

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

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

Власне кажучи, чим більше я думаю про це, тим більше я вважаю, що VS винен, коли робить це, як завжди. Що робити, якщо вказівник const? Чи все-таки це змінять?

Після видалення вказівника пам'ять, на яку він вказує, все ще може бути дійсною. Для виявлення цієї помилки значення вказівника встановлюється на очевидне значення. Це дійсно допомагає процесу налагодження. Якщо значення було встановлено NULL, воно ніколи не відображатиметься як потенційна помилка в потоці програми. Таким чином, він може приховати помилку, коли ви протестуєте пізнішеNULL .

Ще один момент полягає в тому, що деякий оптимізатор часу запуску може перевірити це значення і змінити його результати.

У попередні часи MS встановлювала значення 0xcfffffff.