NULL In a Class Destructor

Question

Possible Duplicate:
Is it worth setting pointers to NULL in a destructor?

Is it pointless to set a pointer (which allocates heap memory) to NULL in the destructor?

class SampleClass
{
    public:
        SampleClass( int Init = 0 )
        {
            Value = new int( Init );
        }

        ~SampleClass( void )
        {
            delete Value;
            Value = NULL; // Is this pointless?
        }

        int *Value;
};

While on the subject of classes, when should I use the explicit keyword?

Exact duplicate of [Is it worth setting pointers to NULL in a destructor?](http://stackoverflow.com/questions/3060006/is-it-worth-setting-pointers-to-null-in-a-destructor) [I agree 100% with Michael Burr's answer, which says in bold, **Do not do this.** ] — James McNellis, Feb 13 '11 at 15:19
The use of `explicit` is explained in ["What does the explicit keyword in C++ mean?"](http://stackoverflow.com/questions/121162/what-does-the-explicit-keyword-in-c-mean) — James McNellis, Feb 13 '11 at 15:21

score 5 · Answer 1 · answered Feb 13 '11 at 15:19

5

Yes. It is pointless, as the object is in the processing of being destroyed. Once it is destroyed, there will be no way to reach the pointer.

answered Feb 13 '11 at 15:19

EvilTeach

28,120
21
85
141

But the memory of the object is not erased. And if you have another pointer to the SampleClass object instance (which can happen - by mistake), you can access the memory. – Matěj Zábský Feb 13 '11 at 15:22
3

@mzabsky If you have that problem, you have better use a smarter pointer so the object isn't prematurely deleted. Trying to defend against bugs in the rest of the program is pretty pointless. – Bo Persson Feb 13 '11 at 15:45

score 4 · Answer 2 · edited Nov 18 '16 at 16:00

Yes, it is meaningless to set the pointer to NULL at the very end of the destructor, as it will not exist anymore as soon as you leave the destructor.

You use the explicit keyword when you want to avoid implicit conversions to your class type. :-)

For example, if MyClass has a constructor taking an int, and a function f(const MyClass&), you can call f either as

f(42)

or

f(MyClass(42))

If you make the constructor explicit, only the latter will work. It can save you from some unwanted implicit conversions.

score 1 · Answer 3 · answered Feb 13 '11 at 15:18

1

It's not really pointless. While it's true that theoretically, the value can never be accessed again, setting it to NULL may well help you in the future if any other shenanigans start going on.

answered Feb 13 '11 at 15:18

Puppy

144,682
38
256
465

1

Although if it does help, it almost certainly won't help as much as setting it to some eye-catcher value would help. – Steve Jessop Feb 13 '11 at 19:57
Nah, NULL specially means, I manually set this. It's not the same. – Puppy Feb 13 '11 at 20:32
2

The value `0xDEADBEEF` does the same, plus it conveys the additional meaning "I set this and hope I don't see it back". – MSalters Feb 14 '11 at 10:19

Matěj Zábský · Answer 4 · 2011-02-13T15:26:15.170

0

It is better to set the pointer to NULL.

If somewhere else in the code you delete the SampleClass instance and then access the Value (using another pointer to the same instance), you will know something went wrong because the program will crash on NULL dereference (so you will know you are accessing deleted object).

Otherwise you could keep using the deleted object and notice the bug only much later (when the memory is overwritten by another object). Such issues are often extremely difficult to debug.

edited Feb 13 '11 at 15:26

answered Feb 13 '11 at 15:18

Matěj Zábský

16,909
15
69
114

3

In the same way, it can be advised never to set that pointer to NULL, if `delete` is called again on the same pointer it will "just work" by ignoring the call, and you will not know that your code has a hidden bug... – David Rodríguez - dribeas Feb 13 '11 at 15:21
@David Rodríguez - dribeas The rule is to reveal bugs as soon as possible = Making the program crash on dereference of the NULLed Value. – Matěj Zábský Feb 13 '11 at 15:24
@David Rodríguez, you better should use asserts or exceptions for this – whyleee Feb 13 '11 at 15:26
3

This is just wrong: dereferencing a pointer to an object that no longer exists is only one kind of error that can occur in this circumstance. As one example, if you `delete p; p = NULL;` in the destructor and then later check `if (p == NULL)`, the code is still wrong and now your check has caused you not to find this error. You are trading the ability to find one sort of error for the ability to find some other sort of error. – James McNellis Feb 13 '11 at 16:54
3

The benefit of _not_ setting the pointer to `NULL` is that a good debug runtime (like the one provided by the Visual C++ debug heap) will fill the contents of freed memory with a recognizable pattern, so it is readily apparent what the error is when you crash; effectively, it enables you to catch _most_ of these errors more easily, far more than you would be able to catch if you set `p = NULL;`. Michael Burr explains this more elegantly in the linked duplicate question. – James McNellis Feb 13 '11 at 16:56

NULL In a Class Destructor

4 Answers4