delete on delete !

[Sandeep Grover]

Hi,

If I do another delete on an object which has been deleted earlier, then
how is
the system expected to behave ?

Is it an unpredictable behavior ??

Thanks
Sandeep

 

[Gianni Mariani]

Hi,

If I do another delete on an object which has been deleted earlier, then
how is
the system expected to behave ?

Is it an unpredictable behavior ??

Yes, unpredictable.

Some will choke, some destructors SEGV, it goes on and on.

 

[Scott Condit]

If I do another delete on an object which has been deleted earlier, then
how is the system expected to behave?

Is it an unpredictable behavior ??

It's undefined, so in theory, yes; anything could happen.

S

 

[Sandeep Grover]

It's undefined, so in theory, yes; anything could happen.

S

Thanks !

So, if I have an array of pointers; more than one of the entries could point
to
the same chunk of memory (allocated using new). How do I ensure that I
end up deleting that entry only once. I dont want to use reference-counting
kind of thing in constructor.

 

[Alf P. Steinbach]

f I have an array of pointers; more than one of the entries could
point to the same chunk of memory (allocated using new). How do I ensure
that I end up deleting that entry only once. I dont want to use
reference-counting kind of thing in constructor.

The sane thing to do would be to use reference-counting.

Reference-counting is automated by many smart-pointers; the most general
and compatible with upcoming standard is boost::shared_ptr (go to
<url:hhtp://www.boost.org> to download the Boost library, it's free).

Without reference-counting you can just sort the array first, on the
pointer values; even though pointers that do not point into the same
variable are not formally comparable, they are comparable in practice.
But you need to know that the array contains pointers to all objects
that you need to delete. And in that case, why not store the unique
pointers in a separate array of the same size or less?

 

[Ioannis Vranos]

Thanks !

So, if I have an array of pointers; more than one of the entries could point
to
the same chunk of memory (allocated using new). How do I ensure that I
end up deleting that entry only once. I dont want to use reference-counting
kind of thing in constructor.

Use a vector of the objects you want, or a list if it suits better the
problem, and not a built in array of pointers.







--
Ioannis

* Programming pages: http://www.noicys.freeurl.com
* Alternative URL 1: http://run.to/noicys
* Alternative URL 2: http://www.noicys.cjb.net

 

[Pete Becker]

Without reference-counting you can just sort the array first, on the
pointer values; even though pointers that do not point into the same
variable are not formally comparable, they are comparable in practice.

If you use std::greater, std::less, std::greater_equal, or
std::less_equal they are comparable. It's just the builtin operators
that are allowed to be fast. <g>

--

"To delight in war is a merit in the soldier,
a dangerous quality in the captain, and a
positive crime in the statesman."
George Santayana

"Bring them on."
George W. Bush

 

[Scott Condit]

Thanks !

So, if I have an array of pointers; more than one of the entries could point
to the same chunk of memory (allocated using new). How do I ensure that I
end up deleting that entry only once. I dont want to use reference-counting
kind of thing in constructor.

A flippant answer would be not to alias pointers.

On the other hand, techniques such as reference-counting
are for when you need multiple pointers to the same object
which you wish to dispose of independently, but don't need
an invasive implementation, i.e. an implementation inside
the pointed-to object.

But this is really a design issue, not a language issue.

S

 

[Chris \( Val \)]

| | > Hi,
| >
| > If I do another delete on an object which has been deleted earlier, then
| > how is
| > the system expected to behave ?
|
|
| It will get angry.

Depends.

| > Is it an unpredictable behavior ??

| Yes it is undefined behaviour. It may die, it may continue living and die
| later, it may truncate data, everything.

Again it depends.

If you set the pointer to zero straight after you have deleted
it, then the behaviour is very defined, and safe.

For example:

# include <iostream>
# include <ostream>

struct Base
{
int N;
};

int main()
{
Base* B = new Base;

delete B;
B = 0; // Introduce a safety net.

for( int Idx( 0 ); Idx < 5; ++Idx )
delete B; // Safe - no opp.

return 0;
}

Cheers.
Chris Val

 

[Ioannis Vranos]

| Yes it is undefined behaviour. It may die, it may continue living and die
| later, it may truncate data, everything.

Again it depends.

If you set the pointer to zero straight after you have deleted
it, then the behaviour is very defined, and safe.

He/she said:

"If I do another delete on an object which has been deleted earlier, then
how is the system expected to behave ?".


That means that the pointer will not point to 0.




--
Ioannis

* Programming pages: http://www.noicys.freeurl.com
* Alternative URL 1: http://run.to/noicys
* Alternative URL 2: http://www.noicys.cjb.net

 

[Chris \( Val \)]

| | >
| >
| > | Yes it is undefined behaviour. It may die, it may continue living and
| die
| > | later, it may truncate data, everything.
| >
| > Again it depends.
| >
| > If you set the pointer to zero straight after you have deleted
| > it, then the behaviour is very defined, and safe.
|
|
| He/she said:
|
| "If I do another delete on an object which has been deleted earlier, then
| how is the system expected to behave ?".

Yes, I know that.

| That means that the pointer will not point to 0.

That is why I said:

*If you set the pointer to zero *straight after* you have deleted it*

Meaning, the first time you delete it, set it to zero, making the
behaviour of deleting it again defined and safe.

Cheers.
Chris Val

 

[Alf P. Steinbach]

| | >
| >
| > | Yes it is undefined behaviour. It may die, it may continue living and
| die
| > | later, it may truncate data, everything.
| >
| > Again it depends.
| >
| > If you set the pointer to zero straight after you have deleted
| > it, then the behaviour is very defined, and safe.
|
|
| He/she said:
|
| "If I do another delete on an object which has been deleted earlier, then
| how is the system expected to behave ?".

Yes, I know that.

| That means that the pointer will not point to 0.

That is why I said:

*If you set the pointer to zero *straight after* you have deleted it*

Meaning, the first time you delete it, set it to zero, making the
behaviour of deleting it again defined and safe.

It's possibly not meaningful to discuss the finer points of language
here, but at least regarding the last few postings there seems to be
confusion about the concept of deleting an object (which cannot be
done without a non-null pointer value) and "deleting a pointer",
probably meaning to use that pointer in a delete expression, which if
it has a technical meaning would be a totally _different_ meaning.

Since the original poster wrote about deleting objects, not pointers,
and furthermore about deleting the same object twice, the only
reasonable interpretation is that what was meant was first deleting
the object, and then performing a delete operation again on the now
invalid pointer value (which for this technically can't be zero).

Setting a pointer to zero after the object it denoted has been
deleted is not an evil practice, though, but don't rely on it to catch
all errors associated with deallocation -- some argue that it might
give a false sense of security + complicates the code + may hide some
errors/bugs, and therefore should be _avoided_ one hundred percent.

 

[Chris \( Val \)]

|
| >
| >| >| | >| >
| >| >
| >| > | Yes it is undefined behaviour. It may die, it may continue living and
| >| die
| >| > | later, it may truncate data, everything.
| >| >
| >| > Again it depends.
| >| >
| >| > If you set the pointer to zero straight after you have deleted
| >| > it, then the behaviour is very defined, and safe.
| >|
| >|
| >| He/she said:
| >|
| >| "If I do another delete on an object which has been deleted earlier, then
| >| how is the system expected to behave ?".
| >
| >Yes, I know that.
| >
| >| That means that the pointer will not point to 0.
| >
| >That is why I said:
| >
| >*If you set the pointer to zero *straight after* you have deleted it*
| >
| >Meaning, the first time you delete it, set it to zero, making the
| >behaviour of deleting it again defined and safe.
|
| It's possibly not meaningful to discuss the finer points of language
| here, but at least regarding the last few postings there seems to be
| confusion about the concept of deleting an object (which cannot be
| done without a non-null pointer value) and "deleting a pointer",
| probably meaning to use that pointer in a delete expression, which if
| it has a technical meaning would be a totally _different_ meaning.

Fair enough.

| Since the original poster wrote about deleting objects, not pointers,
| and furthermore about deleting the same object twice, the only
| reasonable interpretation is that what was meant was first deleting
| the object, and then performing a delete operation again on the now
| invalid pointer value (which for this technically can't be zero).

I understand the context in which the OP posted his/her question.

I only provided an suggestion. That is why I used words such as:
'depends', 'if' and 'after'.

| Setting a pointer to zero after the object it denoted has been
| deleted is not an evil practice, though, but don't rely on it to catch
| all errors associated with deallocation -- some argue that it might
| give a false sense of security + complicates the code + may hide some
| errors/bugs, and therefore should be _avoided_ one hundred percent.

I've never heard anyone suggest that before.
Can you give me an example of where such circumstances can arise ?.

Cheers.
Chris Val

 

[Alf P. Steinbach]

| Setting a pointer to zero after the object it denoted has been
| deleted is not an evil practice, though, but don't rely on it to catch
| all errors associated with deallocation -- some argue that it might
| give a false sense of security + complicates the code + may hide some
| errors/bugs, and therefore should be _avoided_ one hundred percent.

I've never heard anyone suggest that before.
Can you give me an example of where such circumstances can arise ?.

Not that this is my argument, I think the pros and cons nearly cancel
out, but here is one scenario. A firm or shop or project standardizes
on setting pointers to zero after delete. Such pointers can safely be
passed to functions that check for null, and so they're passed around.
In one function there is an incorrect delete via the passed pointer.
This isn't detected because the pointer is null. Later that function
is used with a more valuable real pointer value. It then incorrectly
deletes an object it shouldn't. The effect only shows up much later
in the code execution, and it's then very hard to track down the cause.

 

[Ioannis Vranos]

I've never heard anyone suggest that before.
Can you give me an example of where such circumstances can arise ?.

There are many philosophical approaches. Many believe -including me- that
the second deletion of an object is the last thing of improper use one will
do on it, before he will have tried to read or write to it.

A better use is always use the standard library containers instead of
allocating and deallocating memory explicitly. So for example, instead of
using an array of pointers, use a vector of objects or whatever container of
the standard library fits your purpose better (e.g. a list).







--
Ioannis

* Programming pages: http://www.noicys.freeurl.com
* Alternative URL 1: http://run.to/noicys
* Alternative URL 2: http://www.noicys.cjb.net

 

[Chris \( Val \)]

| | >
| >
| > I've never heard anyone suggest that before.
| > Can you give me an example of where such circumstances can arise ?.
|
|
|
| There are many philosophical approaches. Many believe -including me- that
| the second deletion of an object is the last thing of improper use one will
| do on it, before he will have tried to read or write to it.

Point taken.

| A better use is always use the standard library containers instead of
| allocating and deallocating memory explicitly. So for example, instead of
| using an array of pointers, use a vector of objects or whatever container of
| the standard library fits your purpose better (e.g. a list).

Agreed.

Cheers.
Chris Val

 

[Ashish]

Thanks !

So, if I have an array of pointers; more than one of the entries could point
to
the same chunk of memory (allocated using new). How do I ensure that I
end up deleting that entry only once. I dont want to use reference-counting
kind of thing in constructor.

How can you point two pointers (allocated using new) to the same location???
If you are pointing a pointer to an already allocated piece of memory, you
CANT use the "reference-counting kind of thing in constructor".

The best solution, IMHO, would be to use smart pointers.
[/QUOTE]

 

[Ashish]

| | >
| >
| > | Yes it is undefined behaviour. It may die, it may continue living and
| die
| > | later, it may truncate data, everything.
| >
| > Again it depends.
| >
| > If you set the pointer to zero straight after you have deleted
| > it, then the behaviour is very defined, and safe.
|
|
| He/she said:
|
| "If I do another delete on an object which has been deleted earlier, then
| how is the system expected to behave ?".

Yes, I know that.

| That means that the pointer will not point to 0.

That is why I said:

*If you set the pointer to zero *straight after* you have deleted it*

I think you have misunderstood the problem.
The OP's problem is that more than one pointers point to the same location.

Lets assume that p1 and p2 point to location m1.
Delete m1 using p1.
Set p1 to NULL.
So far so good.
Now, delete p2, the behaviour is undefined. And you had no idea that p2 also
points to m1.

 

[Karl Heinz Buchegger]

| I think you have misunderstood the problem.
| The OP's problem is that more than one pointers point to the same location.
|
| Lets assume that p1 and p2 point to location m1.
| Delete m1 using p1.
| Set p1 to NULL.
| So far so good.
| Now, delete p2, the behaviour is undefined. And you had no idea that p2 also
| points to m1.

Yes, that is true.

However, its the programmers job and responsibility to keep
track of such things, and take preventative measures to avoid
this issue all together.

Exactly.

But especially newbies tend to think: If I set the pointer to
0 immediatly after the delete, nothing bad can happen any more.
This (having a second pointer to the same object) is a counter-
example. That's why lots of programmers warn about setting
a pointer to 0: It creates a false sense of security.
Don't get me wrong: setting a pointer to 0 can't do any harm
and is often a good idea. But it doesn't solve all dynamic
memory related problems.

 

[Chris \( Val \)]

|
|
| "Chris ( Val )" wrote:
| >
| > | I think you have misunderstood the problem.
| > | The OP's problem is that more than one pointers point to the same location.
| > |
| > | Lets assume that p1 and p2 point to location m1.
| > | Delete m1 using p1.
| > | Set p1 to NULL.
| > | So far so good.
| > | Now, delete p2, the behaviour is undefined. And you had no idea that p2 also
| > | points to m1.
| >
| > Yes, that is true.
| >
| > However, its the programmers job and responsibility to keep
| > track of such things, and take preventative measures to avoid
| > this issue all together.
| >
|
| Exactly.
|
| But especially newbies tend to think: If I set the pointer to
| 0 immediatly after the delete, nothing bad can happen any more.
| This (having a second pointer to the same object) is a counter-
| example. That's why lots of programmers warn about setting
| a pointer to 0: It creates a false sense of security.
| Don't get me wrong: setting a pointer to 0 can't do any harm
| and is often a good idea. But it doesn't solve all dynamic
| memory related problems.

Point taken .

Thanks Karl.
Chris Val