Deleting a pointer

[CplusplusNewbie]

I wonder why the authors of C++ didn't write the delete function so
that, for example, the code delete p; stands for

delete p; p = 0;

That way, there would be no problem if pointers were deleted twice.

Is there ever a situation where it would be problematic to set a
pointer to 0 after deletion?

Thank you.

 

[Ron]

I wonder why the authors of C++ didn't write the delete function so
that, for example, the code    delete p;   stands for

delete p;   p = 0;

That way, there would be no problem if pointers were deleted twice.

Is there ever a situation where it would be problematic to set a
pointer to 0 after deletion?

Delete takes an rvalue for an operand. It's not generally possible
for it to modify it.

In actuality, this does hardly much good. Inadvertant twice deletion
is but yet one of
the problems in pointer management. What if that pointer is stored
multiple places?
What happens if someone still dereferences p after it is set to zero?

This only solves one little tiny problem.

Generally, well designed C++ programs don't have need for handling
pointers to dynamic memory directly.
People who write a lot of programs that way are "C" thinking.

 

[Michael Doubez]

I wonder why the authors of C++ didn't write the delete function so
that, for example, the code    delete p;   stands for

delete p;   p = 0;

That way, there would be no problem if pointers were deleted twice.

Except the pointer may not be meant to be deleted twice and if that
happen, it is interesting to know about it. The issue is rather that
delete may be called twice but raise no error. That makes nasty bug to
locate.

Is there ever a situation where it would be problematic to set a
pointer to 0 after deletion?

None. It may even be desirable if the pointer may be initialised/
destroyed in multiple places (or in multiple thread/call).
Or to raise an error if the pointer is deferenced after being
destroyed.

delete of a NULL pointer is safe.

 

[James Kanze]

I wonder why the authors of C++ didn't write the delete
function so that, for example, the code delete p; stands
for

delete p; p = 0;

In the few cases where this buys you something, it's simple to
do yourself. Since delete doesn't require an lvalue, it can't
be required from a simple delete expression, and most of the
time, it doesn't buy you anything anyway.

That way, there would be no problem if pointers were deleted
twice.
Nonsense.

Is there ever a situation where it would be problematic to set
a pointer to 0 after deletion?

No, since any use of the pointer would be undefined behavior
anyway. On the other hand, there aren't many situations where
it would be an advantage, either.

 

[Anand Hariharan]

I wonder why the authors of C++ didn't write the delete function so
that, for example, the code    delete p;   stands for

delete p;   p = 0;

That way, there would be no problem if pointers were deleted twice.

Is there ever a situation where it would be problematic to set a
pointer to 0 after deletion?

Thank you.

FAQ:

http://www.research.att.com/~bs/bs_faq2.html#delete-zero

Also, delete is not a "function".

- Anand

 

[Rolf Magnus]

I wonder why the authors of C++ didn't write the delete function so
that, for example, the code delete p; stands for

delete p; p = 0;

That way, there would be no problem if pointers were deleted twice.

Deleting a pointer twice is the problem. It means there is a logical error
in the code, so setting p to 0 would rather hide that error instead of
removing it.

Is there ever a situation where it would be problematic to set a
pointer to 0 after deletion?

I would say just the double deletion scenario is. If the pointer is set to
0, the second deletion attempt will simply do nothing. If the pointer isn't
set to 0, you usually get a crash and a backtrace that will help you locate
the source of the double-deletion.

 

[Juha Nieminen]

Deleting a pointer twice is the problem. It means there is a logical error
in the code, so setting p to 0 would rather hide that error instead of
removing it.

I'm not sure I fully agree with that. Consider, for example, a smart
pointer class which can point to null or to some allocated object. When
the smart pointer decides that it's ok the delete the object it can
simply perform a 'delete' without worrying whether it's deleting a null
pointer or an actual object.

One could ask "ok, but where's the *double* deletion?" Fair question,
but the situation may well arise if this smart pointer of yours supports
deleting the object before the smart pointer instance goes out of scope.
In that case there will be two deletions: When it's explicitly asked,
and when it falls out of scope. In the latter case situation it will
delete "again", but it's not a symptom of an error.

 

[Lie Ryan]

I'm not sure I fully agree with that. Consider, for example, a smart
pointer class which can point to null or to some allocated object. When
the smart pointer decides that it's ok the delete the object it can
simply perform a 'delete' without worrying whether it's deleting a null
pointer or an actual object.

One could ask "ok, but where's the *double* deletion?" Fair question,
but the situation may well arise if this smart pointer of yours supports
deleting the object before the smart pointer instance goes out of scope.
In that case there will be two deletions: When it's explicitly asked,
and when it falls out of scope. In the latter case situation it will
delete "again", but it's not a symptom of an error.

If such smartness is needed, then perhaps it should be encapsulated with
a class and there is a .delete() method that ensures double deletion
doesn't happen.

 

[James Kanze]

Why would you invoke 'delete' yourself?

Because the program logic has determined that the logical
lifetime of the object has ended.

In the last ten years, I've rarely written any 'delete' in
my code. When I did (count it on your fingers), it was in
the dtor of a class that owned the pointer, so it made no
sense to zero it.

Most of the delete's at the application level in my code are
"delete this". And you obviously can't assign 0 to this.
Another frequent case is the one you describe, where the delete
is in the destructor. And there are cases where the pointer is
in a map or something similar---something like:
T* tmp = someMap[ key ] ;
someMap.erase( key ) ;
delete tmp ;
Since the actual pointer goes immediately out of scope, there's
no point in setting it to zero either. (On the other hand, if
you don't remove the entry from the map, there's likely to be
other problems down the line: either a dangling pointer or a
memory leak.)

 

[Andrey Tarasevich]

I wonder why the authors of C++ didn't write the delete function so
that, for example, the code delete p; stands for

delete p; p = 0;

That way, there would be no problem if pointers were deleted twice.

Pointers are not deleted by 'delete'. What's deleted is the object the
pointer is pointing to. And in 99 cases out of 100 problems with
"multiple deletion" take place when the deletion is attempted through
two (or more) _different_ pointers pointing to the same object.
Obviously, setting pointer to 0 after 'delete' would not solve anything
at all, contrary to your naive "there would be no problem" claim.

 

[Michael Tsang]

Pointers are not deleted by 'delete'. What's deleted is the object the
pointer is pointing to. And in 99 cases out of 100 problems with
"multiple deletion" take place when the deletion is attempted through
two (or more) _different_ pointers pointing to the same object.
Obviously, setting pointer to 0 after 'delete' would not solve anything
at all, contrary to your naive "there would be no problem" claim.

The standard guarantees deleting a NULL pointer is same as doing nothing.
(ISO/IEC 14882 Section 5.3.2)

 

[Richard Herring]

The standard guarantees deleting a NULL pointer is same as doing nothing.
(ISO/IEC 14882 Section 5.3.2)

Which would be fine if that were what you were doing.

What does it say about deleting a copy of the pointer?