Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    text
    copied!<p>Yes, <code>delete this;</code> has defined results, as long as (as you've noted) you assure the object was allocated dynamically, and (of course) never attempt to use the object after it's destroyed. Over the years, many questions have been asked about what the standard says specifically about <code>delete this;</code>, as opposed to deleting some other pointer. The answer to that is fairly short and simple: it doesn't say much of anything. It just says that <code>delete</code>'s operand must be an expression that designates a pointer to an object, or an array of objects. It goes into quite a bit of detail about things like how it figures out what (if any) deallocation function to call to release the memory, but the entire section on <code>delete</code> (§[expr.delete]) doesn't mention <code>delete this;</code> specifically at all. The section on destrucors does mention <code>delete this</code> in one place (§[class.dtor]/13):</p> <blockquote> <p>At the point of definition of a virtual destructor (including an implicit definition (15.8)), the non-array deallocation function is determined as if for the expression delete this appearing in a non-virtual destructor of the destructor’s class (see 8.3.5).</p> </blockquote> <p>That tends to support the idea that the standard considers <code>delete this;</code> to be valid--if it was invalid, its type wouldn't be meaningful. That's the only place the standard mentions <code>delete this;</code> at all, as far as I know.</p> <p>Anyway, some consider <code>delete this</code> a nasty hack, and tell anybody who will listen that it should be avoided. One commonly cited problem is the difficulty of ensuring that objects of the class are only ever allocated dynamically. Others consider it a perfectly reasonable idiom, and use it all the time. Personally, I'm somewhere in the middle: I rarely use it, but don't hesitate to do so when it seems to be the right tool for the job.</p> <p>Edit: [mostly in response to @Alexandre C's comment]: the primary time you do this is with an object that has a life that's almost entirely its own. One example James Kanze has cited was a billing/tracking system he worked on for a phone company. Basically, when you pick up the phone, something takes note of that and creates a <code>phone_call</code> object. From that point onward, the <code>phone_call</code> object handles the details of the phone call (making a connection when you dial, adding an entry to the database to say when the call started, possibly connect more people if you do a conference call, etc.) When you hang up, the <code>phone_call</code> object does its final book-keeping (e.g., adds an entry to the database to say when you hung up, so they can compute how long your call was) and then destroys itself. The lifetime of the <code>phone_call</code> object is based on when you pick up/hang up the phone -- from the viewpoint of the rest of the system, it's basically entirely arbitrary, so you <em>can't</em> tie it to any lexical scope in the code, or anything on that order.</p> <p>For anybody who might care about how dependable this kind of coding can be: if you make a phone call to, from, or through almost any part of Europe, there's a pretty good chance that it's being handled (at least in part) by code that does exactly this.</p>
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload