Create a null pointer after using a delete

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) A pointer is a variable stored on the stack. Variables on the stack cannot be deleted. They are freed automatically at the end of the scope it is in. There is no way in the language to prematurely delete a variable on the stack. Since you must use a pointer to objects stored on the heap, it follows that you cannot delete the pointer that points to what you allocate, but you can delete what the pointer points to.

2) Since you cannot do 1, this makes no sense. You cannot delete a pointer (unless that pointer is stored on the heap).

3) This is not true. How memory is allocated on the heap is implementation defined, which means the compiler and the OS are responsible for it. The language doesn't care or know. Some operating systems may use some sequenced list. Some may not. Modern operating systems such as Windows, Linux and OS certainly do not use sequenced lists. It allocates memory where it is available, i.e. it is smart enough to know where more memory can be allocated.

4) Yes, you need a pointer to it.

5) Yes, a pointer is just a variable that contains memory addresses and since the stack is located in memory, you can point a pointer to a stack variable.

Quote:

---

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

Elysia, you've done it again. Thanks for helping me get things straight in my head, your a great help.

I have a couple of more questions on pointer. Is it possible to have more than one pointer point to the same place in memory? Is this ever done??

Quote:

---

Originally Posted by papagym177

I have a couple of more questions on pointer. Is it possible to have more than one pointer point to the same place in memory? Is this ever done??

---

Yes, it is possible, and it is very common. When sharing data between data structures, it is common to have a pointer to the shared portion. This saves memory since the information does not need to be duplicated. Furthermore, any changes to the shared portion will be reflected in every data structure that contains a pointer to that shared portion. This is one common way where multiple pointers to the same place in memory is used. This pattern is so common that there is a special type of "smart pointer" called shared_ptr that exists for exactly this purpose, to ensure that the common portion of memory is only freed once the last data structure that has a pointer to the data is destroyed, the shared data structure is also freed.

Quote:

---

Originally Posted by papagym177

I have a couple of more questions on pointer. Is it possible to have more than one pointer point to the same place in memory? Is this ever done??

---

This is very common, for instance to iterate through a linked list (or some other structure) allocated on the heap. You might do something like:

Code:

---


for( list* i = head; i != nullptr; i = i->nextElement )

---

This is just one example, but you can see that both i and head point to the same memory at the start.

Quote:

---

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.

Quote:

---

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

Quote:

---

Originally Posted by papagym177

does a smart pointer or shared pointer have any special syntax that will distinguish it from other pointers?

---

A "shared pointer" is a kind of smart pointer. The difference is firstly one of semantics: a shared pointer is used for the semantics of shared ownership, whereas no such semantics would be associated with an ordinary pointer except as established in the code (e.g., to implement a shared pointer). Related to this is the difference of type: a standard shared pointer to an int would be of type std::shared_ptr<int> whereas a pointer to an int would be of type int*. Since a shared_ptr is an object of class type, it can (and does) have member functions that are "special syntax that will distinguish it from other pointers", but this "special syntax" is related to the semantics of shared ownership. Otherwise, the idea is for shared_ptr to have the same pointer syntax as ordinary pointers.

Quote:

---

Originally Posted by papagym177

What really happening when you reference a pointer?

---

I presume that by "reference" you mean "dereference", in which case: it results in what the pointer points to. Beyond this, it depends on the code, compiler, compiler options, etc.

Quote:

---

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.

Quote:

---

There is certainly no guarantee that dereferencing a NULL will cause an immediate crash.

---

Quote:

---

it is silent data corruption or poisoning.

---

O_o

I'd say that neither is most common.

You don't need to collect individual statistics; you just need to read the manual for most common platforms for which statistics already exist.

Certainly, you don't see an immediate crash or get any sort of data corruption on many of the most common platforms; you are offered the opportunity, somehow, to recover from the error. For an example using most modern operating systems running on "x86" flavors: the memory access fails at the processor level thanks to memory segmentation/mapping which is then somehow translated and made available to the program. (To be more specific, on "Windows" you see an "SEH" exception raised while on "Linux" you get `SIGSEGV'.) While obviously not all platforms are "x86" flavors, a large number of platforms offer similar features essentially trapping a derefernce of, whatever it may actually be, null. (Yes, we can include embedded systems where dereferncing null is often the same as illegal instructions which in turn can be trapped.) Oddly, none of this changes the simple fact that dereferencing null is undefined within the C/C++ standards.

Soma

Quote:

---

Originally Posted by phantomotap

For an example using most modern operating systems running on "x86" flavors: the memory access fails at the processor level thanks to memory segmentation/mapping which is then somehow translated and made available to the program.

---

Even if we limit ourselves to x86, the behaviour of the platform (what you've described as "at the processor level" is really the MMU - memory management unit - of modern processors) is shielded from programs by modern operating systems. While you're right that failures "at the processor level" are propagated back to your program (assuming they don't trigger BSOD under windows, unix kernel panics, or similar) a lot of invalid accesses are detected by the OS itself (or by device drivers). That's part of the design in modern multitasking operating systems to prevent one process accessing memory owned by another - and means, among other things, that the memory accessed via a NULL pointer is often unique to a process rather than something that causes the MMU itself to signal an invalid access.

The thing is, different operating systems (and device drivers) have different strategies for how they detect invalid memory accesses, and not all of those strategies directly involve the MMU - which is what triggers those failures you describe as "at the processor level". A consequence of that is that the behaviour on dereferencing NULL (or any other pointer where, according to the C++ standard, the result is undefined) is not set in stone, even for one operating system, let alone when comparing operating systems, or hardware platforms. Which, I assume, is one reason the standard leaves such things undefined, rather than requiring a particular pattern of detection or recovery.

Quote:

---

Even if we limit ourselves [...] of detection or recovery.

---

O_o

I'm clearly combing hardware and operating system with the "platform" vocabulary as most any reading of the example offers not referring specifically to the MMU component as you claim. The distinctions you are trying to make are thus tedious in context, and the comments offered in response to claims never made are irrelevant. Furthermore, some of your claims are misleading; for example, a modern "x86" operating system never mapping anything in the null pointer range (You can make a few configuration changes to the older "Linux" kernel and rebuild allowing you to use the mapped null pointer as a valid address within an application if you really wanted.) as valid for a given application is exactly why the processor does indeed signal an invalid access for the null pointer so the operating system can notify the application.

Soma