delete this??????

[Anamika]

Hello friends....
can anyone tell me what will happen when we do..."delete this"...

 

[Alf P. Steinbach]

* Anamika:

Hello friends....
can anyone tell me what will happen when we do..."delete this"...

The same as happens when you do "delete p" where p is a pointer.

 

[Victor Bazarov]

can anyone tell me what will happen when we do..."delete this"...

The object's destructor is going to be invoked and the pointer to
the current object will be used to free the memory.

If the object wasn't allocated using 'new', the behaviour is
undefined. If any of object's data members or virtual functions
are accessed after 'delete this', the behaviour is undefined.

V

 

[Anamika]

* Anamika:


The same as happens when you do "delete p" where p is a pointer.

--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

no will it give any error message? or it will act madly?

 

[Victor Bazarov]

no will it give any error message? or it will act madly?

Does a regular "delete p" do all that?

 

[Juha Nieminen]

If the object wasn't allocated using 'new', the behaviour is
undefined. If any of object's data members or virtual functions
are accessed after 'delete this', the behaviour is undefined.

From a technical point of view it's not dangerous to execute code
of a member function of a deleted object as long as no member variable
of the object is accessed.
However, what does the C++ standard say?

 

[P.J. Plauger]

Does a regular "delete p" do all that?

No, but it's not necessarily executed within the object being
deleted. The simple answer is that "delete this" works okay,
provided you sneak away carefully after doing so. Do *not*
execute any virtual functions on the way out the door, for
example -- the v-table ain't there anymore, nor are any of
the member objects.

P.J. Plauger
Dinkumware, Ltd.
http://www.dinkumware.com

 

[Victor Bazarov]

No, but it's not necessarily executed within the object being
deleted. The simple answer is that "delete this" works okay,
provided you sneak away carefully after doing so. Do *not*
execute any virtual functions on the way out the door, for
example -- the v-table ain't there anymore, nor are any of
the member objects.

Thanks. That confirms that my first answer to the OP was correct.

V

 

[Victor Bazarov]

From a technical point of view it's not dangerous to execute code
of a member function of a deleted object as long as no member variable
of the object is accessed.

Correct, unless it's a virtual function.

However, what does the C++ standard say?

Nothing special about deleting 'this'. The lifetime of the object
ends when its destructor is invoked. What else do you expect it to
say?

 

[Dave Rahardja]

Hello friends....
can anyone tell me what will happen when we do..."delete this"...

Same as regular delete. Member variables (and most likely virtual functions
too, as the vtable pointer would likely not be available) will no longer be
available after the statement. But other than that, business as usual.

-dr

 

[Juha Nieminen]

Nothing special about deleting 'this'. The lifetime of the object
ends when its destructor is invoked. What else do you expect it to
say?

That code after a "delete this;" is guaranteed to work correctly
as long as 'this' is not accessed (implicitly or explicitly).

I bet it doesn't say that, though, so if we want to ensure complete
compatibility, what should we assume?

 

[Victor Bazarov]

That code after a "delete this;" is guaranteed to work correctly
as long as 'this' is not accessed (implicitly or explicitly).

I bet it doesn't say that, though, so if we want to ensure complete
compatibility, what should we assume?

Assume nothing. Essentially, one needs to get out of that member
function as soon as possible. Basically the safest assumption (if
you just have to assume something) is that any call to any member
functions or use of any data member has undefined behaviour.

V

 

[Default User]

Correct, unless it's a virtual function.

Is that guaranteed? A non-static member function gets a pointer to the
object passed in to it, said pointer now deleted. I think just that use
of the pointer as a function argument causes UB.





Brian

 

[Victor Bazarov]

Is that guaranteed?

Possibly not. We're talking "from a technical point of view".

A non-static member function gets a pointer to the
object passed in to it, said pointer now deleted. I think just that
use of the pointer as a function argument causes UB.

There was a discussion (or several) on what constitues "use". I have
heard/read that there even existed the architecture in which it was
possible to get a hardware exception if a register would contain
an invalid pointer. When in doubt, check.

V

 

[Rolf Magnus]

Is that guaranteed?
No.

A non-static member function gets a pointer to the object passed in to it,
said pointer now deleted. I think just that use of the pointer as a

function argument causes UB.

How member functions are implemented by the compiler doesn't matter. Calling
a non-static member function of a deleted object invokes undefined behavor.
The standard explicitly says that.

 

[Default User]

No.

I wouldn't have thought so, but didn't have time to go through the
standard.

function argument causes UB.

How member functions are implemented by the compiler doesn't matter.
Calling a non-static member function of a deleted object invokes
undefined behavor. The standard explicitly says that.

That's plenty good enough.



Brian

 

[Greg Comeau]

That code after a "delete this;" is guaranteed to work correctly
as long as 'this' is not accessed (implicitly or explicitly).

I bet it doesn't say that, though, so if we want to ensure complete
compatibility, what should we assume?

Do you mean it should say so explicitly? It doesn't need to.

 

[James Kanze]

No, but it's not necessarily executed within the object being
deleted.

Not necessarily, but code which tries to avoid delete this often
ends up doing it in a function called from within the object,
which amounts to the same thing.

The simple answer is that "delete this" works okay,
provided you sneak away carefully after doing so.

Which is true for delete p as well. Anytime you delete
something, don't use any pointer to the deleted object. The
this pointer isn't special in this regards.

The one thing you might be concerned about is that when you do
"delete this", you know that there is at least one pointer to
the object still floating around; the one which whoever called
you has. In my experience, however, there are almost always
more than one pointer to the object floating around, regardless
of who does the delete, and that you have to design to take this
into account, and ensure that these other pointers are
eliminated. (The observer pattern is very useful here.) So
"delete this" doesn't really change anything in this regard
either.

Do *not*
execute any virtual functions on the way out the door, for
example -- the v-table ain't there anymore, nor are any of
the member objects.

In fact, the "delete this" should be the last thing you do in
the function, period (except maybe for any logging saying that
you're leaving the function). Again, it's more or less the same
rule I use for "delete p"---That line should be the last line in
the scope in which p is defined.

 

[James Kanze]

From a technical point of view it's not dangerous to execute code
of a member function of a deleted object as long as no member variable
of the object is accessed.
However, what does the C++ standard say?

It says it's OK, as long as no non-static member is accessed.
Calling a member function (even a non-virtual one) is undefined
behavior, and of course, any access to a non-static data member
is undefined behavior.

In practice, if "delete this" weren't the last thing you do in
the function (except maybe some logging), I'd be very unhappy.
(In a similar way, I don't like deleting an arbitrary pointer
except when the pointer is immediately going out of scope.)

 

[James Kanze]

That code after a "delete this;" is guaranteed to work correctly
as long as 'this' is not accessed (implicitly or explicitly).

I bet it doesn't say that, though, so if we want to ensure complete
compatibility, what should we assume?

Well, it certainly doesn't say that: if it did, I'd put all the
entire application in one function which did "delete this" at
the top, and never have to debug again.

But you're right to ask: an implementation might conceivably
store the return address in the object, or some silliness like
that. In fact, the standard does set up a set of very specific
rules. As long as you obey those rules, an implementation is
required to make your code work. Since there is nothing in the
rules which says you cannot "delete this", it is OK, as long as
you obey the rest of the rules. (One of those rules say, for
example, that you cannot even read the this pointer without
incurring undefined behavior. Also, you cannot access any
non-static member, including calling a non-static function,
since this involves reading the this pointer.)

The issue was discussed before the standard was adopted, and the
concensus was that "delete this" is legal. (There's even an
example where the code explicitly calls this->~C(). Not quite
"delete this", but most of the same issues apply.)