   Odd habit
  Anyone share this very odd habit?class foo{public:   foo()   {   mObject = new Object();   }   ~foo()   {   if(mObject)   {  delete mObject;  mObject = NULL;   }   }   Object* mObject;};:PEven though I know delete will gracefully handle NULL values, and that I really don't need to set the pointer to NULL when the object is destructed, I still test, delete, set to NULL.Anyone else in this habit?   
  No, I don't find myself testing for NULL pointers before deleting them.  However I always set them to NULL afterward.   ;  I tend to do:ASSERT(pBuffer);delete (pBuffer);pBuffer= NULL;and, if it is something i'm reusing i do the same at the newASSERT(!pBuffer);pBuffer = new char[1024];But not so often with the class you outlined above (which needs a copy constructor). Where in I usually feel ok about the pointer being ok. When I'm doing more heavy handed memory management I get more liberal with asserting the values of the pointers.;  Not really. I even can't remember the last time I used a bald pointer...   ;  In directX when releasing an object I always check if it's there, although it's more along the lines of this if(pObject){    pObject->Release();    pObject = NULL;}and then that's wrapped into a macro called SAFE_RELEASE.   ;Quote:Not really. I even can't remember the last time I used a bald pointer... I can, but it was pointing to something on the stack so. Eh.You may prefer using 0 to NULL because it is consistent with boolean checks ( if(ptr) is if (ptr != 0), not if (ptr != NULL). But you might also prefer NULL because it signals intent, and also because on some systems NULL != 0.Very shortly, however, you will want to prefer nullptr. http://en.wikipedia.org/wiki/C%2B%2B0x#Null_pointer_constant   ;Quote:Original post by leet bixIn directX when releasing an object I always check if it's there, although it's more along the lines of this *** Source Snippet Removed ***and then that's wrapped into a macro called SAFE_RELEASE.This is different though, because you're actually calling a function on the passed-in object.On another note, why use a macro? Why not just make it a function?   ;  I would neither check for NULL, nor assign it afterwards (in a destructor). I don't make a habbit of writing unnecessary code.If you're hoping to find enough people doing the same to satify yourself that it is a good idea, then I shall politely suggest otherwise.   ;  There's no need to set a pointer member variable to NULL in a class' destructor, however if it's a pointer that will be allocated and deleted several times while staying in scope then I definately test and set for/to NULL before allocating and after deleting.   ;  Actually, I do find myself doing that sometimes for some reason.  It's a waste of code and running time, but I do it anyway accidentally out of habit I guess.It's safe to use delete on a null pointer anyway, isn't it?  And if the object is going away it's not going to matter if its children get set to null or not since those pointers aren't going to get used again anyway, but it's a hard habit for me to kick regardless.   