Thread: Create a null pointer after using a delete

Originally Posted by papagym177

In jumping into C++ it says something like this: It's not necessary but when you delete a pointer it's a good idea to reset it as a null pointer. That if your code try's to dereference the pointer after being freed, your program will crash. This happens to a lot of experienced programmers This could corrupt users data.
delete p_int;
p_int = NULL;

This raises a lot of questions for me as a beginners.

1. If you can deference a pointer after the memory is freed, why can't you just delete the pointer?

2. If you can do 1, how do you delete the pointer using code?

3. Every thing I've read says that free memory is handed out in a sequenced order. I don't believe that is true at all. I may be wrong. Why can't you put the data in any number of places if it will fit. Isn't the compiler smart enough to know where bytes (bits)and pieces are stored?

4. If you storing anything in free memory must use a pointer to it?

5. Can a pointer or something similar be used with stack memory?

1) "Deleting" a pointer causes it's destructor to be called (if any) and then relinquishes ownership of that chunk of memory back to the system to be used elsewhere. So the pointer itself is still going to contain that memory address. If you then try to dereference the pointer things may seem to work normally for a while or the program may well crash at any point. Setting it to NULL ensures that an error will be raised the moment you try to dereference the invalid pointer.

2) Just as you have it: "delete p_int;". For an array you would use the "delete[] p_int;".

3) No, the implementation is free to dole it out however it likes.

4) It sounds like you're asking if an allocated chunk should have at least one pointer attached to it? If so, yes, because otherwise you'd have a memory leak.

5) Absolutely! Just don't "delete" something that hasn't been allocated with "new".

Oh, and once you understand how pointers work, be sure to study up on the principles of RAII...

Originally Posted by Sebastiani

Setting it to NULL ensures that an error will be raised the moment you try to dereference the invalid pointer.

That's not true. Dereferencing a NULL pointer is just as much undefined behaviour as dereferencing a pointer to something that no longer exists as far as the program is concerned. There is certainly no guarantee that dereferencing a NULL will cause an immediate crash.

In practice, any form of undefined behaviour (dereferencing a NULL, dereferencing a pointer to something that doesn't exist, falling off the end of an array, modifying a variable twice in a single statement, etc etc) can result in intermittent or unpredictable behaviour. And often does.

The usual reason for setting a pointer to NULL after deleting it is that NULL can be tested for (e.g. "if (pointer != NULL) dereference(pointer);"). It is not to give a guaranteed crash for dereferencing the pointer.

Originally Posted by grumpy

That's not true. Dereferencing a NULL pointer is just as much undefined behaviour as dereferencing a pointer to something that no longer exists as far as the program is concerned. There is certainly no guarantee that dereferencing a NULL will cause an immediate crash.

In practice, any form of undefined behaviour (dereferencing a NULL, dereferencing a pointer to something that doesn't exist, falling off the end of an array, modifying a variable twice in a single statement, etc etc) can result in intermittent or unpredictable behaviour. And often does.

The usual reason for setting a pointer to NULL after deleting it is that NULL can be tested for (e.g. "if (pointer != NULL) dereference(pointer);"). It is not to give a guaranteed crash for dereferencing the pointer.

Okay, perhaps it isn't well-defined, but AFAIK most systems will behave in such a way, so it is still practically true. Just don't bank on it.

Elysia, does a smart pointer or shared pointer have any special syntax that will distinguish it from other pointers? What really happening when you dereference a pointer? Thanks

Originally Posted by Sebastiani

Okay, perhaps it isn't well-defined, but AFAIK most systems will behave in such a way, so it is still practically true. Just don't bank on it.

There is certainly a perception that a crash is the most common symptom of pointer molestation, simply because it is most blatant. And an immediate crash is often viewed as being more common than others, simply because it is easier to induce and easier to track down.

In practice, although I haven't collected formal statistics, I would suggest the most common symptom is not a crash it all: it is silent data corruption or poisoning. However, such symptoms aren't visible immediately and aren't necessarily easy to induce repeatably, so developers default to believing they are rare. A deferred crash (data gets corrupted, that data is used by some unrelated code as a pointer or array dimension/index, some other data gets corrupted <repeat a few times>, leading to an eventual crash at some point in code unrelated to the original problem) is at least as common as an immediate crash too.

That's why I advocate techniques to prevent such problems, rather than (the more common approach by most developers) trying to find them after the fact.