Чи є гарною практикою NULL покажчик після його видалення?

Почну, кажу, використовуйте розумні вказівники, і вам ніколи про це не доведеться хвилюватися.

Які проблеми з наведеним нижче кодом?

Foo * p = new Foo;
// (use p)
delete p;
p = NULL;

Це було викликано відповіддю та коментарями до іншого питання. Один коментар Ніла Баттерворта приніс кілька результатів:

Встановлення покажчиків на NULL після видалення не є універсальною хорошою практикою в C ++. Бувають випадки, коли це добре робити, і періоди, коли це безглуздо і може приховати помилки.

Існує маса обставин, коли це не допоможе. Але, на мій досвід, це не зашкодить. Хтось мене просвітить.

Встановлення вказівника на 0 (що є "null" у стандартному C ++, значення NULL від C дещо інше) дозволяє уникнути збоїв на подвійних видаленнях.

Розглянемо наступне:

Foo* foo = 0; // Sets the pointer to 0 (C++ NULL)
delete foo; // Won't do anything

При цьому:

Foo* foo = new Foo();
delete foo; // Deletes the object
delete foo; // Undefined behavior 

Іншими словами, якщо ви не встановите видалені покажчики на 0, у вас виникнуть проблеми, якщо ви робите подвійне видалення. Аргументом проти встановлення покажчиків на 0 після видалення буде те, що це маскує подвійне видалення помилок і залишає їх без обробки.

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

Нарешті, сторонне позначення щодо управління розподілом об’єктів, я пропоную вам ознайомитись із std::unique_ptrсуворим / єдиним правом власності, std::shared_ptrспільним володінням або іншою реалізацією інтелектуального вказівника, залежно від ваших потреб.

Якщо встановити покажчики на NULL після того, як ви видалили те, на що вказувалося, це, безумовно, не може зашкодити, але це часто є невід'ємною допомогою для більш фундаментальної проблеми: Чому ви в першу чергу використовуєте покажчик? Я бачу дві типові причини:

• Ви просто хотіли, щоб щось було виділено на купі. У такому випадку загортання його в об'єкт RAII було б набагато безпечнішим та чистішим. Закінчіть область об’єкта RAII, коли об’єкт більше не потрібен. Ось так std::vectorпрацює, і це вирішує проблему випадкового залишення покажчиків на розселену пам’ять навколо. Покажчиків немає.
• Або, можливо, вам потрібна складна семантика спільної власності. Вказівник, повернутий з якого, newможе бути не таким, як той, що deleteвикликається. Кілька об'єктів, можливо, тим часом використовували об'єкт. У такому випадку кращим буде загальний покажчик або щось подібне.

Моє правило: якщо ви залишаєте покажчики в коді користувача, ви робите це неправильно. Вказівник не повинен бути там, щоб в першу чергу вказувати на сміття. Чому не існує об'єкта, який несе відповідальність за забезпечення його дійсності? Чому сфера його дії не закінчується, коли об'єкт із вказаним об'єктом робить?

У мене є ще краща найкраща практика: Де можливо, закінчіть область застосування змінної!

{
    Foo* pFoo = new Foo;
    // use pFoo
    delete pFoo;
}

Я завжди встановлюю вказівник на NULL(зараз nullptr) після видалення об'єкта (ів), на який він вказує.

1. Це може допомогти зафіксувати багато посилань на звільнену пам'ять (якщо припустити, що ваша платформа виявила помилки на дереві нульового вказівника).

2. Він не зафіксує всі посилання на вільну пам'ять, якщо, наприклад, у вас є копії вказівника. Але деякі краще, ніж ніхто.

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

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

5. Якщо ви вже використовуєте RAII, то deleteу вашому коді не так багато s, тому аргумент того, що додаткове призначення викликає захаращення, не переконує мене.

6. Часто зручно під час налагодження бачити нульове значення, а не застарілий покажчик.

7. Якщо це все-таки турбує вас, використовуйте натомість розумний вказівник або посилання.

Я також встановлюю інші типи ручок ресурсу для значення без ресурсу, коли ресурс вільний (що, як правило, лише в деструкторі оболонки RAII, написаному для інкапсуляції ресурсу).

Я працював над великим комерційним продуктом (9 мільйонів тверджень) (насамперед на С). Одного разу ми застосували макро-магію, щоб обнулити покажчик при звільненні пам'яті. Це негайно виявило безліч ховаючих помилок, які були негайно виправлені. Наскільки я пам'ятаю, у нас ніколи не було помилок з подвійною вільністю.

Оновлення: Microsoft вважає, що це хороша практика безпеки та рекомендує цю практику в політиці SDL. Мабуть, MSVC ++ 11 автоматично заглушить видалений вказівник (за багатьох обставин), якщо ви компілюєте параметр / SDL.

По-перше, існує багато питань щодо цієї та тісно пов'язаних тем, наприклад, чому б не видалити встановити вказівник на NULL? .

У вашому коді питання, що відбувається далі (використовуйте p). Наприклад, якщо десь у вас є такий код:

Foo * p2 = p;

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

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

Якщо після цього буде більше коду delete, Так. Коли вказівник видаляється в конструкторі або в кінці методу чи функції, Ні.

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

Ще кращою практикою є використання розумних покажчиків (спільних або масштабних), які автоматично видаляють цільові об’єкти.

Як вже говорили інші, delete ptr; ptr = 0;демони не вилітають з вашого носа. Однак це все-таки заохочує використання ptrв якості прапора. Код засмічується deleteта встановлює покажчик на NULL. Наступним кроком є if (arg == NULL) return;розповсюдження коду для захисту від випадкового використання NULLвказівника. Проблема виникає після того, як перевірки NULLна предмет стануть вашим основним засобом перевірки стану об'єкта чи програми.

Я впевнений, що є запах коду щодо використання вказівника як прапора десь, але я його не знайшов.

Я трохи зміню ваше запитання:

Чи використовуєте ви неініціалізований покажчик? Знаєте, той, на який ви не встановили NULL або виділили пам'ять, на яку він вказує?

Є два сценарії, коли встановлення вказівника на NULL можна пропустити:

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

Тим часом, стверджуючи, що встановлення вказівника на NULL може приховати помилки для мене звучить як аргументація того, що ви не повинні виправляти помилку, оскільки виправлення може приховати ще одну помилку. Єдині помилки, які можуть відображатися, якщо вказівник не встановлений на NULL, будуть ті, які намагаються використовувати вказівник. Але встановлення його на NULL насправді призведе до точно такої ж помилки, як і при використанні звільненої пам'яті, чи не так?

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

Для мене питання не в тому "це гарна ідея?" але "яку поведінку я б заважав чи дозволив досягти успіху, роблячи це?" Наприклад, якщо це дозволяє іншому коду бачити, що вказівник більше недоступний, чому інший код навіть намагається подивитися на звільнені вказівники після їх звільнення? Зазвичай це клоп.

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

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

Якщо це те, що ви насправді маєте на увазі, краще зробити це явне у джерелі, використовуючи щось на зразок boost :: необов’язковий

optional<Foo*> p (new Foo);
// (use p.get(), but must test p for truth first!...)
delete p.get();
p = optional<Foo*>();

Але якщо ви дійсно хотіли, щоб люди знали, що вказівник "пішов погано", я погоджусь на 100% згоду з тими, хто каже, що найкраще зробити - це змусити його вийти за межі сфери. Тоді ви використовуєте компілятор для запобігання можливості поганих відхилень під час виконання.

Це дитина у всій воді C ++, не повинна викидати її. :)

У добре структурованій програмі з відповідною перевіркою помилок немає причин не призначати її недійсною. 0окремо стоїть як загальновизнане недійсне значення в цьому контексті. Невдача і невдача.

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

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

Добре структуровані програми можуть бути розроблені за допомогою функцій C ++, щоб уникнути цих випадків. Ви можете використовувати посилання, або ви можете просто сказати "передача / використання нульових або недійсних аргументів - це помилка" - підхід, який однаково застосовний до контейнерів, таких як розумні покажчики. Посилення послідовної та правильної поведінки забороняє цим клопам добиратися далеко.

Звідси ви маєте лише обмежену область застосування та контекст, де може існувати (або дозволено) нульовий покажчик.

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

Нарешті, у вашому компіляторі та середовищі, ймовірно, є якісь запобіжники для тих часів, коли ви хочете ввести помилки (прошивання), виявити доступ до звільненої пам’яті та зловити інші пов'язані UB. Ви також можете вводити подібну діагностику у свої програми, часто не впливаючи на існуючі програми.

Дозвольте мені розкрити те, що ви вже поставили у своєму питанні.

Ось що ви поставили у своєму питанні у формі кулі:

Встановлення покажчиків на NULL після видалення не є універсальною хорошою практикою в C ++. Бувають випадки, коли:

• це добре робити
• і часи, коли це безглуздо і може приховати помилки.

Однак немає випадків, коли це погано ! Ви не будете вводити більше помилок, чітко скасуючи їх, ви не просочите пам’ять, не будете спричиняти не визначену поведінку .

Тож, якщо сумніваєтесь, просто обнуліть його.

Сказавши, що якщо ви відчуваєте, що вам потрібно явно обнулити якийсь вказівник, то для мене це звучить так, що ви недостатньо розділили метод, і слід переглянути підхід рефакторингу під назвою "Метод вилучення", щоб розділити метод на окремі частини.

Так.

Єдина «шкода», яку вона може зробити - це ввести неефективність (непотрібна робота магазину) у вашу програму - але ця накладні витрати будуть незначними щодо витрат на виділення та звільнення блоку пам’яті у більшості випадків.

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

Я завжди використовую макрос для видалення:

#define SAFEDELETE(ptr) { delete(ptr); ptr = NULL; }

(і подібне для масиву, free (), випускаючи ручки)

Ви також можете записати методи самовидалення, які посилаються на покажчик коду виклику, тому вони змушують покажчик коду виклику на NULL. Наприклад, для видалення піддерева багатьох об'єктів:

static void TreeItem::DeleteSubtree(TreeItem *&rootObject)
{
    if (rootObject == NULL)
        return;

    rootObject->UnlinkFromParent();

    for (int i = 0; i < numChildren)
       DeleteSubtree(rootObject->child[i]);

    delete rootObject;
    rootObject = NULL;
}

редагувати

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

Існує також багато способів, як ви могли реалізувати вищесказане - я просто намагаюся проілюструвати ідею змусити людей NULL вказівника, якщо вони видаляють об'єкт, а не надавати їм засоби для звільнення пам'яті, яка не NULL вказівника абонента. .

Звичайно, наведений вище приклад - це лише крок до автопоказника. Що я не запропонував, оскільки ОП спеціально розпитував про випадок не використання автоматичного вказівника.

"Бувають випадки, коли це добре робити, і періоди, коли це безглуздо і може приховати помилки"

Я бачу дві проблеми: Цей простий код:

delete myObj;
myobj = 0

стає для вкладиша у багатопотокове середовище:

lock(myObjMutex); 
delete myObj;
myobj = 0
unlock(myObjMutex);

"Найкраща практика" Дон Нойфельда застосовується не завжди. Наприклад, в одному автомобільному проекті нам довелося встановити покажчики на 0 навіть у деструкторах. Я можу уявити, що в критичному для безпеки програмному забезпеченні такі правила не рідкість. Легше (і розумно) слідувати за ними, ніж намагатися переконати команду / перевірку коду для кожного використання вказівника у коді, що рядок, що скасовує цей покажчик, є зайвим.

Ще одна небезпека полягає у покладанні на цю техніку у використанні винятків:

try{  
   delete myObj; //exception in destructor
   myObj=0
}
catch
{
   //myObj=0; <- possibly resource-leak
}

if (myObj)
  // use myObj <--undefined behaviour

У такому коді ви створюєте витік ресурсів і відкладаєте проблему, або процес виходить з ладу.

Отже, ці дві проблеми, які мимоволі проходять через мою голову (Герб Саттер точно б розповів більше), ставлять для мене всі питання типу "Як уникнути використання смарт-покажчиків і виконувати роботу безпечно з нормальними покажчиками" як застарілі.

Завжди є покажчики, що турбуються.

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

Як багато хто говорив, звичайно набагато простіше просто використовувати розумні покажчики.

Редагувати: Як сказав Томас Меттьюз у цій попередній відповіді , якщо покажчик видалений у деструкторі, немає необхідності присвоювати йому NULL, оскільки він більше не буде використаний, оскільки об’єкт вже знищується.

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

Якщо код не належить до найважливішої частини вашої програми, будьте прості та використовуйте shared_ptr:

shared_ptr<Foo> p(new Foo);
//No more need to call delete

Він виконує підрахунок довідок і є безпечним для потоків. Ви можете знайти його в tr1 (std :: tr1 простір імен, #include <memory>) або якщо ваш компілятор не надає його, отримайте його з boost.