Odd 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 new

ASSERT(!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



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 bix In 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.

Useless code makes it look more complicated than it actually is. It is such a rare case for me to use keyword delete, I dont have any habits associated with it. Almost always smart pointers do the job for me.

Hi, i do have this habit, but i use a macro defined in a .h file that look like this:

// SafeKill.h
#ifndef SAFE_DESTRUCTOR
#define SAFE_DESTRUCTOR
#ifdef __cplusplus

//These helper macro will release or delete safely the passed object
#define SAFE_RELEASE(x) if((x) != NULL){(x)->Release();(x) = NULL;}
#define SAFE_DELETE_ARRAY(x) if((x) != NULL){delete[] (x);(x) = NULL;}
#define SAFE_DELETE_OBJECT(x) if((x) != NULL){delete (x);(x) = NULL;}

#endif
#endif //SAFE_DESTRUCTOR

I dont really use SAFE_RELEASE(the first one), but i do use SAFE_DELETE_ARRAY a TON and sometime SAFE_DELETE_OBJECT.

Setting a member to null in a destructor is just plain useless.

Used to do that, before I found out delete (T*)0; is a no-op. I also null-after-delete (except in destructors).

My odd habits have more to do with OCD-like tendencies for pointing out things such as the OP's class not conforming to the Rule of Three, even though it'd be a complete tangent to the problem in question.

Quote:

Original post by Vortez Hi, i do have this habit, but i use a macro defined in a .h file that look like this: // SafeKill.h #ifndef SAFE_DESTRUCTOR #define SAFE_DESTRUCTOR #ifdef __cplusplus //These helper macro will release or delete safely the passed object #define SAFE_RELEASE(x) if((x) != NULL){(x)->Release();(x) = NULL;} #define SAFE_DELETE_ARRAY(x) if((x) != NULL){delete[] (x);(x) = NULL;} #define SAFE_DELETE_OBJECT(x) if((x) != NULL){delete (x);(x) = NULL;} #endif #endif //SAFE_DESTRUCTOR I dont really use SAFE_RELEASE(the first one), but i do use SAFE_DELETE_ARRAY a TON and sometime SAFE_DELETE_OBJECT.

It's strange that you use the latter two often but not so much the first - unless I'm mistaken, the first one is the only one that actually has any benefit! (Unless you intend to re-use the pointer for some reason, in which case the 'setting it to null' part isn't a bad idea. But you could still get rid of the conditionals, since they really don't contribute anything.)

Also:

Quote:

Original post by jyk On another note, why use a macro? Why not just make it a function?

Quote:

Original post by jyk It's strange that you use the latter two often but not so much the first - unless I'm mistaken, the first one is the only one that actually has any benefit! (Unless you intend to re-use the pointer for some reason, in which case the 'setting it to null' part isn't a bad idea. But you could still get rid of the conditionals, since they really don't contribute anything.)

SAFE_DELETE_ARRAY is usefull for dynamic array created with the "new" operator, and i use SAFE_DELETE_OBJECT for non-array stuff. But the first one is for malloc i think, but i always use new instead of malloc, i just find it simplier.

I written those macro a long time ago, back when i started programming so i must have seen that somewhere and made macro with them, but i use it in almost every of my projects. The speed isin't an issue because i generally use it once or a couple of time in a fonction then im done. Unless u use those macro in a very big loop and use it a lot, i don't see any problem with that.

Im gonna make some test with and without the test and post the result back.

Edit: For your second question, why use a macro, well because i find macro is more suitable for this task, but i know the flamming around macro so im just giving my opinion there. But it's true that now that im experienced i tend to avoid macro if i can, but those are nice.

Quote:

Edit: For your second question, why use a macro, well because i find macro is more suitable for this task, but i know the flamming around macro so im just giving my opinion there.

Can I ask why you think a macro is more suitable here? Just curious...

Here my result:

10 Millions Loop of allocating and desallocating 64 bytes(using the high-precision timer, not tickCount)

with if: 5.176914 sec
without if: 5.169494 sec

So, not a big loss there...

Quote:

Original post by jyk Can I ask why you think a macro is more suitable here? Just curious... Quote: Original post by Vortez Edit: For your second question, why use a macro, well because i find macro is more suitable for this task, but i know the flamming around macro so im just giving my opinion there.

Honestly i dunno, i guess i got use to it.

I think a good programmer has no room in his or her toolbox for superstition.

Checking for null pointers and assigning values in a destructor is a practice that will grow hair on your palms, possibly make you sterile, and likely land you in hell.

Quote:

Original post by Deyja on some systems NULL != 0

But the conversion of the integral constant 0 to an pointer type is guaranteed to give you a valid null pointer value for that type, regardless of what the actual bit pattern of the null pointer value is.