Which version of safe_delete is better?

问题

#define SAFE_DELETE(a) if( (a) != NULL ) delete (a); (a) = NULL;

OR

template<typename T> void safe_delete(T*& a) {
  delete a;
  a = NULL;
}

or any other better way

回答1:

Clearly the function, for a simple reason. The macro evaluates its argument multiple times. This can have evil side effects. Also the function can be scoped. Nothing better than that :)

回答2:

I would say neither, as both will give you a false sense of security. For example, suppose you have a function:

void Func( SomePtr * p ) {
  // stuff
  SafeDelete( p );
}

You set p to NULL, but the copies of p outside the function are unaffected.

However, if you must do this, go with the template - macros will always have the potential for tromping on other names.

回答3:

delete a;

ISO C++ specifies, that delete on a NULL pointer just doesn't do anything.

Quote from iso 14882:

    5.3.5 Delete [expr.delete]

    2   [...] In either alternative, if the value of the operand of delete is the 
        null pointer the operation has no effect. [...]

Regards, Bodo

/edit: I didn't notice the a=NULL; in the original post, so new version: delete a; a=NULL; however, the problem with setting a=NULL has already been pointed out (false feeling of security).

回答4:

Generally, prefer inline functions over macros, as macros don't respect scope, and may conflict with some symbols during preprocessing, leading to very strange compile errors.

Of course, sometimes templates and functions won't do, but here this is not the case.

Additionally, the better safe-delete is not necessary, as you could use smart-pointers, therefore not requiring to remember using this method in the client-code, but encapsulating it.

(edit) As others have pointed out, safe-delete is not safe, as even if somebody does not forget to use it, it still may not have the desired effect. So it is actually completely worthless, because using safe_delete correctly needs more thought than just setting to 0 by oneself.

回答5:

You don't need to test for nullity with delete, it is equivalent to a no-op. (a) = NULL makes me lift an eyebrow. The second option is better.

However, if you have a choice, you should use smart pointers, such as std::auto_ptr or tr1::shared_ptr, which already do this for you.

回答6:

I think

#define SAFE_DELETE(pPtr) { delete pPtr; pPtr = NULL } is better

1. its ok to call delete if pPtr is NULL. So if check is not required.
2. in case if you call SAFE_DELETE(ptr+i), it will result in compilation error.
3. Template definition will create multiple instances of the function for each data type. In my opinion in this case, these multiple definitions donot add any value.
4. Moreover, with template function definition, you have overhead of function call.

回答7:

Usage of SAFE_DELETE really appears to be a C programmers approach to commandeering the built in memory management in C++. My question is: Will C++ allow this method of using a SAFE_DELETE on pointers that have been properly encapsulated as Private? Would this macro ONLY work on pointer that are declared Public? OOP BAD!!

回答8:

As mentioned quite a bit above, the second one is the better one, not a macro with potential unintended side effects, doesn't have the unneeded check against NULL (although I suspect you are doing that as a type check), etc. But neither are promising any safety. If you do use something like tr1::smart_ptr, please make sure you read the docs on them and are sure that it has the right semantics for your task. I just recently had to hunt down and clean up a huge memory leak due to a co-worker putting smart_ptrs into a data structure with circular links :) (he should have used weak_ptrs for back references)

回答9:

I prefer this version:

~scoped_ptr() {
    delete this->ptr_; //this-> for emphasis, ptr_ is owned by this
}

Setting the pointer to null after deleting it is quite pointless, as the only reason that you would use pointers is to allow an object to be referenced in multiple places at once. Even if the pointer in one part of the program is 0 there may well be others that are not set to 0.

Furthermore the safe_delete macro / function template is very difficult to use right, because there are only two places that it can be used if there is code that may throw between the new and delete for the given pointer.

1) Inside either a catch (...) block that rethrows the exception and also duplicated next to the catch (...) block for the path that doesn't throw. (Also duplicated next to every break, return, continue etc that may allow the pointer to fall out of scope)

2) Inside a destructor for an object that owns the pointer (unless there is no code between the new and delete that can throw).

Even if there is no code that could throw when you write the code, this could change in the future (all it takes is for someone to came along and add another new after the first one). It is better write code in a way that stays correct even in the face of exceptions.

Option 1 creates so much code duplication and is so easy to get wrong that I am doubtful to even call it an option.

Option 2 makes safe_delete redundant, as the ptr_ that you are setting to 0 will go out of scope on the next line.

In summary -- don't use safe_delete as it is not safe at all (it is very difficult to use correctly, and leads to redundant code even when its use is correct). Use SBRM and smart pointers.

来源：https://stackoverflow.com/questions/540920/which-version-of-safe-delete-is-better