473,322 Members | 1,379 Online
Bytes | Software Development & Data Engineering Community
Post Job

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 473,322 software developers and data experts.

deleting an object twice?

Hi,

Does deleting an object more than one times incur undefined behavior? I
think it doesn't but just making sure... thanks

Rick

Jul 22 '05 #1
15 3561
Rick wrote:

Hi,

Does deleting an object more than one times incur undefined behavior?
The first delete renders the pointer to it invalid. Using an
invalid pointer invokes undefined behaviour.
I
think it doesn't but just making sure... thanks


You are wrong.
--
Karl Heinz Buchegger
kb******@gascad.at
Jul 22 '05 #2
"Rick" <rrquick@nospam-com> wrote in message
news:3f********@clarion.carno.net.au...
Hi,

Does deleting an object more than one times incur undefined behavior? I
think it doesn't but just making sure... thanks

Rick


Are you setting your pointer to null after the first delete? I think you
have deleting a null pointer mixed up with deleting a pointer twice. I am
not sure if this is a standard behavior or not but on the few compilers that
I have worked with delete checks for a null pointer and does nothing.
Jul 22 '05 #3
Rick wrote:
Hi,

Does deleting an object more than one times incur undefined behavior? I
think it doesn't but just making sure... thanks

Rick


It does. Delete renders a pointer to be invalid and so calling delete again
will result in undefined behaviour. To circumvent this, simply set the
pointer to NULL after deletion. Calling delete for a NULL pointer will do
nothing.

--
Dipl.-Inform. Hendrik Belitz
Central Laboratory of Electronics
Research Center Juelich
Jul 22 '05 #4
On Fri, 05 Dec 2003 03:08:58 +1100, Rick <rrquick@nospam-com> wrote:
Hi,

Does deleting an object more than one times incur undefined behavior? I
think it doesn't but just making sure... thanks


int* p = new int;
delete p;
delete p; //undefined behaviour

Generally double deletes cause heap corruption and, if you're lucky, a
crash. You can of course delete null pointers as often as you like.
e.g.

int* p = new int;
delete p;
p = 0;
delete p; //fine

Tom

C++ FAQ: http://www.parashift.com/c++-faq-lite/
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
Jul 22 '05 #5
> Does deleting an object more than one times incur undefined behavior? I
think it doesn't but just making sure... thanks


How can you possibly delete an object more than once? Once you have deleted
it, it no longer exists, so what are you deleting the second time?

If you are thinking of something like this:

int* p = new int;
delete p;
delete p;

then after the first "delete p", p is an invalid pointer -- the only thing
you can do with p is give it a new value.

So there is no question of deleting "an object" twice.
Jul 22 '05 #6
Andrew Koenig wrote:
Does deleting an object more than one times incur undefined behavior?
I think it doesn't but just making sure... thanks
How can you possibly delete an object more than once?
Once you have deleted it, it no longer exists,
so what are you deleting the second time?

If you are thinking of something like this:

int* p = new int;
delete p;
delete p;

then after the first "delete p", p is an invalid pointer --


I object to your abuse of the English language.
The pointer p is *not* deleted.
The *object* to which pointer p points is deleted.
Pointer p is a valid pointer to an invalid object
(of type int in this case) because delete calls
the object's destructor to destroy the object.
the only thing you can do with p is give it a new value.

So there is no question of deleting "an object" twice.


The problem is that the second delete
is almost certainly a programming error -- a bug.
If you simply set the pointer p = NULL,
the bug will go undetected.
You can't do anything about this for built-in types
but you can for User Defined Types (UDTs):

class X {
private:
int Valid;
// other data members
public:
X(void) Valid(0x55555555) { }
~X(void) {
if (0x55555555 == Valid)
Valid == 0xaaaaaaaa;
else
std::cerr << "Invalid object of type X!" << std::endl;
}
// other public functions and operators
};

Jul 22 '05 #7
"E. Robert Tisdale" <E.**************@jpl.nasa.gov> wrote in message
news:3F**************@jpl.nasa.gov...
Andrew Koenig wrote:
Does deleting an object more than one times incur undefined behavior?
I think it doesn't but just making sure... thanks
How can you possibly delete an object more than once?
Once you have deleted it, it no longer exists,
so what are you deleting the second time?

If you are thinking of something like this:

int* p = new int;
delete p;
delete p;

then after the first "delete p", p is an invalid pointer --


I object to your abuse of the English language.
The pointer p is *not* deleted.


Who said it was?
The *object* to which pointer p points is deleted.
As far as I can see, neither the OP nor AK have stated or implied that it is
the pointer being deleted. Only the C++ source code says that :-)
Pointer p is a valid pointer to an invalid object
(of type int in this case) because delete calls
the object's destructor to destroy the object.
the only thing you can do with p is give it a new value.

So there is no question of deleting "an object" twice.


The problem is that the second delete
is almost certainly a programming error -- a bug.
If you simply set the pointer p = NULL,
the bug will go undetected.


I'd say that would fix the bug rather than hide it, albeit unsatisfactorily.
And in some circumstances two deletes are quite normal. An object's member
pointer to a valid object might or might not have been deleted and assigned
to null before the destructor is reached, so you would like the destructor
to delete it regardless.

DW

Jul 22 '05 #8
"E. Robert Tisdale" <E.**************@jpl.nasa.gov> wrote in message
news:3F**************@jpl.nasa.gov...
Andrew Koenig wrote:
Does deleting an object more than one times incur undefined behavior?
I think it doesn't but just making sure... thanks
How can you possibly delete an object more than once?
Once you have deleted it, it no longer exists,
so what are you deleting the second time?

If you are thinking of something like this:

int* p = new int;
delete p;
delete p;

then after the first "delete p", p is an invalid pointer --


I object to your abuse of the English language.
The pointer p is *not* deleted.


I don't think Andrew said so; he just said: "after the first "delete p"". He
didn't say that the pointer was deleted.
The *object* to which pointer p points is deleted.
Pointer p is a valid pointer to an invalid object
(of type int in this case) because delete calls
the object's destructor to destroy the object.
the only thing you can do with p is give it a new value.

So there is no question of deleting "an object" twice.
The problem is that the second delete
is almost certainly a programming error -- a bug.
If you simply set the pointer p = NULL,
the bug will go undetected.


It is not necessarilly a bug. There is a reason why you can do a delete on a
null pointer.
You can't do anything about this for built-in types
but you can for User Defined Types (UDTs):

class X {
private:
int Valid;
// other data members
public:
X(void) Valid(0x55555555) { }
~X(void) {
if (0x55555555 == Valid)
Valid == 0xaaaaaaaa;
else
std::cerr << "Invalid object of type X!" << std::endl;
}
// other public functions and operators
};


Even though this technique may work on some platforms with some compilers
under certain circumstances, it is not *guaranteed* to work. Once an object
has been deleted, the memory it occupied may have been overwritten, unmapped
(resulting in a page fault) or occupied by another object (possibly of the
same class). There is also a chance the vtable pointer of the deleted object
is damaged; if the pointer is used to call any virtual member function
(including the destructor) on the deleted object very weird things may
happen - good for hours of debugging fun.

Personnally I prefer resetting the pointer to NULL after deleting the object
it is pointing to. That way it easy to detect if the pointer is still
pointing to a valid object, and on most platforms leads to very predictable
behaviour when that pointer is accidentally dereferenced. Resetting the
pointer does not conflict with using a member variable to see if the object
is still valid. Even tough that technique is not 100% reliable, it increases
the chance that code that shouldn't work doesn't work (which is usually a
good thing). Member functions (not just the destructor) can use the member
variable with the magic number as a precondition. This technique can be
especially useful to detect lifetime issues i.c.w. having multiple pointers
to the same object.
--
Peter van Merkerk
peter.van.merkerk(at)dse.nl


Jul 22 '05 #9
How can you possibly delete an object more than once?
Once you have deleted it, it no longer exists,
so what are you deleting the second time?

If you are thinking of something like this:

int* p = new int;
delete p;
delete p;

then after the first "delete p", p is an invalid pointer --
I object to your abuse of the English language.


That's your prerogative. Mine is to say that you're mistaken :-)
The pointer p is *not* deleted.
I never said it was.
The *object* to which pointer p points is deleted.
Yes, that's what I said.
Pointer p is a valid pointer to an invalid object
(of type int in this case) because delete calls
the object's destructor to destroy the object.
Wrong. Once you have said "delete p", the value of p is now invalid. For
example, in

int* p = new int;
delete p;
int* q = p;

the attempt to copy p in order to initialize q yields undefined behavior, so
the implementation can do as it pleases.
the only thing you can do with p is give it a new value. So there is no question of deleting "an object" twice.

The problem is that the second delete
is almost certainly a programming error -- a bug.
Yes, indeed -- I never said otherwise.
If you simply set the pointer p = NULL,
the bug will go undetected.
Yes indeed -- I never said otherwise.
You can't do anything about this for built-in types
but you can for User Defined Types (UDTs):

class X {
private:
int Valid;
// other data members
public:
X(void) Valid(0x55555555) { }
~X(void) {
if (0x55555555 == Valid)
Valid == 0xaaaaaaaa;
else
std::cerr << "Invalid object of type X!" << std::endl;
}
// other public functions and operators
};


And your point is what, exactly? Are you claiming that C++ requires some
particular behavior in the case of

X* p = new X;
delete p;
delete p;

It doesn't; the implementation can do as it pleases.
Jul 22 '05 #10
Andrew Koenig wrote:
How can you possibly delete an object more than once?
Once you have deleted it, it no longer exists,
so what are you deleting the second time?

If you are thinking of something like this:

int* p = new int;
delete p;
delete p;

then after the first "delete p", p is an invalid pointer --
I object to your abuse of the English language.


That's your prerogative. Mine is to say that you're mistaken :-)
The pointer p is *not* deleted.


I never said it was.


I never said that you said that it was.
Ali R., Hendrik Belitz and tom_usenet said that it was.
The *object* to which pointer p points is deleted.


Yes, that's what I said.
Pointer p is a valid pointer to an invalid object
(of type int in this case) because delete calls
the object's destructor to destroy the object.


Wrong. Once you have said "delete p", the value of p is now invalid.
For example, in

int* p = new int;
delete p;
int* q = p;

the attempt to copy p in order to initialize q yields undefined behavior
so the implementation can do as it pleases.


Where is it written? (Please cite and quote the relevant document.)

Please compile and run the above code fragment on a platform
where the behavior is other than expected
and show us the diagnostic and/or incorrect result.
the only thing you can do with p is give it a new value.So there is no question of deleting "an object" twice.
The problem is that the second delete
is almost certainly a programming error -- a bug.


Yes, indeed -- I never said otherwise.


I never said that you said otherwise.
If you simply set the pointer p = NULL,
the bug will go undetected.


Yes indeed -- I never said otherwise.


I never said that you said otherwise.
You can't do anything about this for built-in types
but you can for User Defined Types (UDTs):

class X {
private:
int Valid;
// other data members
public:
X(void) Valid(0x55555555) { }
~X(void) {
if (0x55555555 == Valid)
Valid == 0xaaaaaaaa;
else
std::cerr << "Invalid object of type X!" << std::endl;
}
// other public functions and operators
};


And your point is what, exactly?
Are you claiming that
C++ requires some particular behavior in the case of

X* p = new X;
delete p;
delete p;


I made no such claim.
It doesn't; the implementation can do as it pleases.


I never said differently.

Please don't take my remarks personally. They are directed at
other subscribers reading this thread and *not* just you.

Jul 22 '05 #11

"E. Robert Tisdale" <E.**************@jpl.nasa.gov> wrote in message news:3F************@jpl.nasa.gov...
the attempt to copy p in order to initialize q yields undefined behavior
so the implementation can do as it pleases.


Where is it written? (Please cite and quote the relevant document.)


5.3.5/4 of the C++ stanard

Jul 22 '05 #12
> I never said that you said that it was.

You said that I was abusing the English language. The only reason I could
imagine that you might make such a statement was that you thought I had said
something incorrect or unclear. So I went over each statement I made, in
order to point out why I think it is correct.
Pointer p is a valid pointer to an invalid object
(of type int in this case) because delete calls
the object's destructor to destroy the object.
Wrong. Once you have said "delete p", the value of p is now invalid.
For example, in

int* p = new int;
delete p;
int* q = p;

the attempt to copy p in order to initialize q yields undefined behavior
so the implementation can do as it pleases.


Where is it written? (Please cite and quote the relevant document.)


C++ standard, subclause 5.3.5, paragraph 4: "Note: The value of a pointer
that refers to deallocated storage is indeterminate."
Please compile and run the above code fragment on a platform
where the behavior is other than expected
and show us the diagnostic and/or incorrect result.


Attempting to use the value of an indeterminate pointer yields undefined
behavior, so an implementation is allowed to do as it plases with the
example above. Therefore, there is no such thing as unexpected behavior --
any behavior at all is permissible.
The problem is that the second delete
is almost certainly a programming error -- a bug.


Yes, indeed -- I never said otherwise.


I never said that you said otherwise.


See above.
If you simply set the pointer p = NULL,
the bug will go undetected.


Yes indeed -- I never said otherwise.


I never said that you said otherwise.


See above.
And your point is what, exactly?
Are you claiming that
C++ requires some particular behavior in the case of

X* p = new X;
delete p;
delete p;


I made no such claim.
It doesn't; the implementation can do as it pleases.


I never said differently.

Please don't take my remarks personally. They are directed at
other subscribers reading this thread and *not* just you.


Then why did you claim that I was abusing the English language?
Jul 22 '05 #13

"E. Robert Tisdale" <E.**************@jpl.nasa.gov> wrote in message
news:3F************@jpl.nasa.gov...
Andrew Koenig wrote:
How can you possibly delete an object more than once?
Once you have deleted it, it no longer exists,
so what are you deleting the second time?

If you are thinking of something like this:

int* p = new int;
delete p;
delete p;

then after the first "delete p", p is an invalid pointer --

I object to your abuse of the English language.


That's your prerogative. Mine is to say that you're mistaken :-)
The pointer p is *not* deleted.


I never said it was.


I never said that you said that it was.
Ali R., Hendrik Belitz and tom_usenet said that it was.


But you implied it when you said:
[quote snippet]
I object to your abuse of the English language.
The pointer p is *not* deleted.
[end quote]

What did you mean by this if you didn't mean what we think you mean?
Jul 22 '05 #14
David White wrote:
"E. Robert Tisdale" <E.**************@jpl.nasa.gov> wrote in message
news:3F**************@jpl.nasa.gov...
Andrew Koenig wrote:
>>Does deleting an object more than one times incur undefined
>>behavior? I think it doesn't but just making sure... thanks
>
> How can you possibly delete an object more than once?
> Once you have deleted it, it no longer exists,
> so what are you deleting the second time?
>
> If you are thinking of something like this:
>
> int* p = new int;
> delete p;
> delete p;
>
> then after the first "delete p", p is an invalid pointer --
I object to your abuse of the English language.
The pointer p is *not* deleted.


Who said it was?
The *object* to which pointer p points is deleted.


As far as I can see, neither the OP nor AK have stated or implied that
it is the pointer being deleted. Only the C++ source code says that
:-)
Pointer p is a valid pointer to an invalid object
(of type int in this case) because delete calls
the object's destructor to destroy the object.
> the only thing you can do with p is give it a new value.
>
> So there is no question of deleting "an object" twice.


The problem is that the second delete
is almost certainly a programming error -- a bug.
If you simply set the pointer p = NULL,
the bug will go undetected.


I'd say that would fix the bug rather than hide it, albeit
unsatisfactorily. And in some circumstances two deletes are quite
normal.


I see this as a design error. Each new should have exactly one delete,
certainly not less, but also not more. And IMHO, a good design will
prevent any intended double deletions. Setting the pointer to 0 after
delete might be a useful thing for release versions to prevent a crash
due to an overlooked double deletion. But while debugging, I want to
find those and thus don't want to set the pointer to 0. If at all, I'd
set it to something that enforces a crash.
An object's member pointer to a valid object might or might
not have been deleted and assigned to null before the destructor is
reached, so you would like the destructor to delete it regardless.


Then the ownership isn't clear. A dynamically allocated object should
have an owner that is responsible for deleting it.

Jul 22 '05 #15
"Rolf Magnus" <ra******@t-online.de> wrote in message news:bq*************@news.t-online.com...
David White wrote:
I'd say that would fix the bug rather than hide it, albeit
unsatisfactorily. And in some circumstances two deletes are quite
normal.


I see this as a design error. Each new should have exactly one delete,
certainly not less, but also not more. And IMHO, a good design will
prevent any intended double deletions. Setting the pointer to 0 after
delete might be a useful thing for release versions to prevent a crash
due to an overlooked double deletion. But while debugging, I want to
find those and thus don't want to set the pointer to 0. If at all, I'd
set it to something that enforces a crash.


I don't see how you can always avoid double deletions. The logic of a class might dictate that
an object it created, and for which it has a member pointer, might or might not have been
deleted by the time the destructor is reached, or might not have been created at all. If it has
already been deleted, it might also have to be assigned to null because it might be used to
point to another new object later, e.g.,

class Device
{
BaseProtocol *m_pProt;
public:
Device() : m_pProt(0) {}
~Device() { delete m_pProt; }
bool Open(ProtocolType protType)
{
delete m_pProt;
switch(protType)
{ case TCP_IP:
m_pProt = new TcpIpProtocol; break;
case IPX_SPX:
m_pProt = new IpxSpxProtocol; break;
// more protocols
};
if(!m_pProt->Connect())
{ delete m_pProt; m_pProt = 0; return false;
}
return true;
}
// more members
};
An object's member pointer to a valid object might or might
not have been deleted and assigned to null before the destructor is
reached, so you would like the destructor to delete it regardless.


Then the ownership isn't clear. A dynamically allocated object should
have an owner that is responsible for deleting it.


It's clear in the cases I was thinking of. The object that owns the pointer creates the object.

DW

Jul 22 '05 #16

This thread has been closed and replies have been disabled. Please start a new discussion.

Similar topics

6
by: Thomas Philips | last post by:
I have a question about deleting objects. My game has two classes, Player and Alien, essentially identical, instances of which can shoot at each other. Player is described below class...
6
by: Matan Nassau | last post by:
Hello. i have a composite which i want to delete. this is a composite which represents a boolean expression (see a previous post of mine with more details at...
9
by: Aguilar, James | last post by:
Hey guys. A new question: I want to use an STL libarary to hold a bunch of objects I create. Actually, it will hold references to the objects, but that's beside the point, for the most part. ...
12
by: Christoff Pale | last post by:
Hi, suppose I have a list of strings; I have to iterate of the strings and delete certain entries. I and not sure how to do this? for example: #include<list> #include<string>...
4
by: al havrilla | last post by:
hi all what does the phrase: "scalar deleting destructor" mean? i'm getting this in a debug error message using c++ 7.1 thanks Al
5
by: Patrick Vanden Driessche | last post by:
Hi All, I'm currently writing an in-house Form validation framework (WinForms) which is based on 'Component'-inheriting object. So basically, I have a small hierarchy. FormValidator +--...
6
by: belmontpress | last post by:
I wish to delete some files from a directory after reading them but have the problem that the system says that the files are in use and cannot delete them even though I have set the StreamReader to...
51
by: Joe Van Dyk | last post by:
When you delete a pointer, you should set it to NULL, right? Joe
12
by: mc | last post by:
Hi Experts, This may be obvious but I can't find anything one way or another. We have a class which is always allocated using new, e.g. Foo* foo = new Foo() so we came up with the idea of...
0
by: ryjfgjl | last post by:
ExcelToDatabase: batch import excel into database automatically...
0
isladogs
by: isladogs | last post by:
The next Access Europe meeting will be on Wednesday 6 Mar 2024 starting at 18:00 UK time (6PM UTC) and finishing at about 19:15 (7.15PM). In this month's session, we are pleased to welcome back...
0
by: ArrayDB | last post by:
The error message I've encountered is; ERROR:root:Error generating model response: exception: access violation writing 0x0000000000005140, which seems to be indicative of an access violation...
1
by: PapaRatzi | last post by:
Hello, I am teaching myself MS Access forms design and Visual Basic. I've created a table to capture a list of Top 30 singles and forms to capture new entries. The final step is a form (unbound)...
1
by: Defcon1945 | last post by:
I'm trying to learn Python using Pycharm but import shutil doesn't work
1
by: Shællîpôpï 09 | last post by:
If u are using a keypad phone, how do u turn on JavaScript, to access features like WhatsApp, Facebook, Instagram....
0
by: af34tf | last post by:
Hi Guys, I have a domain whose name is BytesLimited.com, and I want to sell it. Does anyone know about platforms that allow me to list my domain in auction for free. Thank you
0
by: Faith0G | last post by:
I am starting a new it consulting business and it's been a while since I setup a new website. Is wordpress still the best web based software for hosting a 5 page website? The webpages will be...
0
isladogs
by: isladogs | last post by:
The next Access Europe User Group meeting will be on Wednesday 3 Apr 2024 starting at 18:00 UK time (6PM UTC+1) and finishing by 19:30 (7.30PM). In this session, we are pleased to welcome former...

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.