| | >
| >
| > | 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.