Deleting a pointer
CplusplusNewbie
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
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.
--
Michael
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.
--
James Kanze (GABI Software) email:james...@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
Anand Hariharan
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
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.
Markus Raab
> 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;
>
#define delete(x) delete x; x=0;
int main()
{
int *p = new int;
int *q = p;
delete(q);
delete(p);
}
Because it just doesn't make any sense and does not help you with your
problem (check out what aliases are).
Markus
Hendrik Schober
Why would you invoke 'delete' yourself?
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.
> Thank you.
Schobi
James Kanze
> CplusplusNewbie wrote:
> > 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?
> 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.)
Hendrik Schober
> On Jun 29, 12:06 pm, Hendrik Schober <spamt...@gmx.de> wrote:
>> CplusplusNewbie wrote:
>>> 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?
>
>> Why would you invoke 'delete' yourself?
>
> Because the program logic has determined that the logical
> lifetime of the object has ended.
Usually that would mean dismissing the (last) smart pointer
that holds the object, for example, by popping it off some
container.
>> 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.)
Why would you store naked pointers in a container?
Schobi
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.
--
Best regards,
Andrey Tarasevich
Michael Tsang
The standard guarantees deleting a NULL pointer is same as doing nothing.
(ISO/IEC 14882 Section 5.3.2)
Pete Becker
Yes, but that doesn't help.
int *ip = new int;
int *ip1 = ip;
delete ip; ip = 0;
delete ip1; // bang!
--
Pete
Roundhouse Consulting, Ltd. (www.versatilecoding.com) Author of
"The Standard C++ Library Extensions: a Tutorial and Reference"
(www.petebecker.com/tr1book)
Richard Herring
<mik...@gmail.com> writes
>Andrey Tarasevich wrote:
>
>> CplusplusNewbie wrote:
>>> 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.
>>
>
>(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?
--
Richard Herring