Там какая-либо причина состоит в том, чтобы проверить на Нулевого указателя перед удалением?

Стандарт C++ гарантирует, что законно использовать нулевого указателя в удалять-выражение (В§8.5.2.5/2). Однако это неуказанное , вызовет ли это функцию освобождения (operator delete или operator delete[]; В§8.5.2.5/7, отметьте).

, Если функция освобождения по умолчанию (т.е. обеспеченный стандартной библиотекой) вызвана с нулевым указателем, то вызов не имеет никакого эффекта (В§6.6.4.4.2/3).

, Но это является неуказанным, что происходит, если функция освобождения не обеспечивается стандартной библиотекой — В т.е. что происходит, когда мы перегружаемся operator delete (или operator delete[]).

А компетентный программист обработал бы нулевых указателей соответственно внутренний функция освобождения, а не перед вызовом, как показано в коде OP’s. Аналогично, устанавливая указатель на [1 110] / NULL после того, как удаление только служит очень ограниченной цели. Некоторым людям нравится делать это в духе [1 127] безопасное программирование : это сделает поведение программы немного более предсказуемым в случае ошибки: доступ к указателю после удаления приведет к доступу к нулевому указателю, а не доступу к случайной ячейке памяти. Хотя обе операции являются неопределенным поведением, поведение доступа к нулевому указателю намного более предсказуемо на практике (это чаще всего приводит к прямому катастрофическому отказу, а не повреждению памяти). Так как повреждения памяти особенно трудно отладить, сбрасывание удаленных указателей помогает отладке.

klass* pobj = new klass;
// … use pobj.
delete pobj;

// 1st step: allocate memory
klass* pobj = static_cast<klass*>(operator new(sizeof(klass)));
// 2nd step: construct object in that memory, using placement new:
new (pobj) klass();

// … use pobj.

// 3rd step: call destructor on pobj:
pobj->~klass();
// 4th step: free memory
operator delete(pobj);

void* operator new(size_t size) {
    // See Effective C++, Item 8 for an explanation.
    if (size == 0)
        size = 1;

    cerr << "Allocating " << size << " bytes of memory:";

    while (true) {
        void* ret = custom_malloc(size);

        if (ret != 0) {
            cerr << " @ " << ret << endl;
            return ret;
        }

        // Retrieve and call new handler, if available.
        new_handler handler = set_new_handler(0);
        set_new_handler(handler);

        if (handler == 0)
            throw bad_alloc();
        else
            (*handler)();
    }
}

void operator delete(void* p) {
    cerr << "Freeing pointer @ " << p << "." << endl;
    custom_free(p);
}

int main() {
    int* pi = new int(42);
    cout << *pi << endl;
    delete pi;
}

Allocating 4 bytes of memory: @ 0x100160
42
Freeing pointer @ 0x100160.

void operator delete(void* p) {
    if (p == 0) return;
    cerr << "Freeing pointer @ " << p << "." << endl;
    free(p);
}

Удалите проверки на ПУСТОЙ УКАЗАТЕЛЬ внутренне. Ваш тест избыточен

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

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

Если pSomeObject будет ПУСТЫМ, удалите, ничего то не сделает. Так не, Вы не должны проверять на ПУСТОЙ УКАЗАТЕЛЬ.

Мы считаем это хорошей практикой для присвоения ПУСТОГО УКАЗАТЕЛЯ указателю после удаления его, если вообще возможно, что некоторый knucklehead может попытаться использовать указатель. Используя Нулевого указателя немного лучше, чем использование указателя на то, кто знает то, что (Нулевой указатель вызовет катастрофический отказ, указатель на удаленную память не может)

Нет никакой причины проверить на ПУСТОЙ УКАЗАТЕЛЬ до, удаляют. Присвоение ПУСТОГО УКАЗАТЕЛЯ после удаляет, могло бы быть необходимым, если где-нибудь в проверках кода сделаны, выделяется ли некоторый объект уже путем выполнения ПУСТОЙ проверки. Примером были бы своего рода кэшированные данные, которые выделяются по требованию. Каждый раз, когда Вы убираете объект кэша, Вы присваиваете ПУСТОЙ УКАЗАТЕЛЬ указателю так код, который выделяет объект, знает, что он должен выполнить выделение.

Я полагаю, что предыдущий разработчик кодировал его "избыточно" для сохранения некоторых миллисекунд: это - хорошая вещь иметь указатель быть установленным в NULL после того, чтобы быть удаленным, таким образом, Вы могли использовать строку как следующее право после удаления объекта:

if(pSomeObject1!=NULL) pSomeObject1=NULL;

, Но тогда удаляют, делает то точное сравнение так или иначе (выполнение ничего, если это является ПУСТЫМ). Почему делают это дважды? Можно всегда присваивать pSomeObject ПУСТОМУ УКАЗАТЕЛЮ после того, как вызов удаляет, независимо от его текущего значения - но это было бы немного избыточно, если бы он уже имел то значение.

, Таким образом, моя ставка является автором тех строк, которые попробовали, чтобы удостовериться, что pSomeObject1 всегда будет ПУСТЫМ, будучи удаленным, не подвергаясь стоимости потенциально ненужного теста и присваивания.

Это зависит от того, что Вы делаете. Некоторые более старые реализации free, например, не будут счастливы, если они будут переданы NULL указатель. Некоторые библиотеки все еще имеют эту проблему. Например, XFree в библиотеке Xlib говорит:

ОПИСАНИЕ

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

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

Что касается моих наблюдений, удаление нулевого указателя с помощью delete безопасно на машинах на базе unix, например PARISC и itanium. Но это довольно небезопасно для систем Linux, так как в этом случае процесс выйдет из строя.