Is delete this allowed in C

Question

Is it allowed to delete this  if the delete-statement is the last statement that will be executed on that instance of the class  Of course I m sure that the object represented by the this-pointer is newly-created   I m thinking about something like this   void SomeModule  doStuff            in the controller   this  object of SomeModule is the  current module         now  if I want to switch over to a new Module  eg       controller- gt setWorkingModule new OtherModule             since the new  OtherModule  object will take the lead          I want to get rid of this  SomeModule  object       delete this      Can I do this

User · Answer

You can do so   However  you can t assign to this   Thus the reason you state for doing this   I want to change the view   seems very questionable   The better method  in my opinion  would be for the object that holds the view to replace that view     Of course  you re using RAII objects and so you don t actually need to call delete at all   right

User · Answer

If it scares you  there s a perfectly legal hack   void myclass  delete me         std  unique ptr lt myclass gt  bye bye this       I think delete this is idiomatic C   though  and I only present this as a curiosity   There is a case where this construct is actually useful - you can delete the object after throwing an exception that needs member data from the object  The object remains valid until after the throw takes place   void myclass  throw error         std  unique ptr lt myclass gt  bye bye this       throw std  runtime exception this- gt error msg       Note  if you re using a compiler older than C  11 you can use std  auto ptr instead of std  unique ptr  it will do the same thing

User · Answer

It is allowed  just do not use the object after that   but I wouldn t write such code on practice  I think that delete this should appear only in functions that called release or Release and looks like  void release     ref--  if  ref lt 1  delete this

User · Answer

Yes  delete this  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 delete this   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 delete 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 delete     expr delete   doesn t mention delete this  specifically at all  The section on destrucors does mention delete this in one place     class dtor  13       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     That tends to support the idea that the standard considers delete this  to be valid--if it was invalid  its type wouldn t be meaningful  That s the only place the standard mentions delete this  at all  as far as I know   Anyway  some consider delete this 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   The primary time you use this technique 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  When start to you make a phone call  something takes note of that and creates a phone call object  From that point onward  the phone call 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 the last people on the call hang up  the phone call 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 phone call object is based on when the first person starts the call and when the last people leave the call--from the viewpoint of the rest of the system  it s basically entirely arbitrary  so you can t tie it to any lexical scope in the code  or anything on that order   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

User · Answer

Delete this is legal as long as object is in heap  You would need to require object to be heap only  The only way to do that is to make the destructor protected - this way delete may be called ONLY from class   so you would need a method that would ensure deletion

User · Answer

One of the reasons that C   was designed was to make it easy to reuse code   In general  C   should be written so that it works whether the class is instantiated on the heap  in an array  or on the stack    Delete this  is a very bad coding practice because it will only work if a single instance is defined on the heap  and there had better not be another delete statement  which is typically used by most developers to clean up the heap   Doing this also assumes that no maintenance programmer in the future will cure a falsely perceived memory leak by adding a delete statement   Even if you know in advance that your current plan is to only allocate a single instance on the heap  what if some happy-go-lucky developer comes along in the future and decides to create an instance on the stack   Or  what if he cuts and pastes certain portions of the class to a new class that he intends to use on the stack   When the code reaches  delete this  it will go off and delete it  but then when the object goes out of scope  it will call the destructor   The destructor will then try to delete it again and then you are hosed   In the past  doing something like this would screw up not only the program but the operating system and the computer would need to be rebooted   In any case  this is highly NOT recommended and should almost always be avoided   I would have to be desperate  seriously plastered  or really hate the company I worked for to write code that did this

User · Answer

This is an old  answered  question  but  Alexandre asked  Why would anyone want to do this    and I thought that I might provide an example usage that I am considering this afternoon   Legacy code  Uses naked pointers Obj obj with a delete obj at the end     Unfortunately I need sometimes  not often  to keep the object alive longer   I am considering making it a reference counted smart pointer   But there would be lots of code to change  if I was to use ref cnt ptr lt Obj gt  everywhere   And if you mix naked Obj  and ref cnt ptr  you can get the object implicitly deleted when the last ref cnt ptr goes away  even though there are Obj  still alive   So I am thinking about creating an explicit delete ref cnt ptr   I e  a reference counted pointer where the delete is only done in an explicit delete routine   Using it in the one place where the existing code knows the lifetime of the object  as well as in my new code that keeps the object alive longer   Incrementing and decrementing the reference count as explicit delete ref cnt ptr get manipulated   But NOT freeing when the reference count is seen to be zero in the explicit delete ref cnt ptr destructor   Only freeing when the reference count is seen to be zero in an explicit delete-like operation  E g  in something like   template lt typename T gt  class explicit delete ref cnt ptr     private      T  ptr     int rc          public      void delete if rc0           if  this- gt ptr             this- gt rc--          if  this- gt rc    0                delete this- gt ptr                    this- gt ptr   0                      OK  something like that   It s a bit unusual to have a reference counted pointer type not automatically delete the object pointed to in the rc ed ptr destructor   But it seems like this might make mixing naked pointers and rc ed pointers a bit safer   But so far no need for delete this   But then it occurred to me  if the object pointed to  the pointee  knows that it is being reference counted  e g  if the count is inside the object  or in some other table   then the routine delete if rc0 could be a method of the pointee object  not the  smart  pointer   class Pointee     private      int rc          public      void delete if rc0             this- gt rc--          if  this- gt rc    0                delete this                                Actually  it doesn t need to be a member method at all  but could be a free function   map lt void  int gt  keepalive map  template lt typename T gt  void delete if rc0 T ptr            void  tptr    void  ptr          if  keepalive map tptr     1                delete ptr                  BTW  I know the code is not quite right - it becomes less readable if I add all the details  so I am leaving it like this

User · Answer

This is the core idiom for reference-counted objects   Reference-counting is a strong form of deterministic garbage collection- it ensures objects manage their OWN lifetime instead of relying on  smart  pointers  etc  to do it for them  The underlying object is only ever accessed via  Reference  smart pointers  designed so that the pointers increment and decrement a member integer  the reference count  in the actual object   When the last reference drops off the stack or is deleted  the reference count will go to zero  Your object s default behavior will then be a call to  delete this  to garbage collect- the libraries I write provide a protected virtual  CountIsZero  call in the base class so that you can override this behavior for things like caching   The key to making this safe is not allowing users access to the CONSTRUCTOR of the object in question  make it protected   but instead making them call some static member- the FACTORY- like  static Reference CreateT        That way you KNOW for sure that they re always built with ordinary  new  and that no raw pointer is ever available  so  delete this  won t ever blow up

User · Answer

The C   FAQ Lite has a entry specifically for this   https   isocpp org wiki faq freestore-mgmt delete-this   I think this quote sums it up nicely      As long as you re careful  it s OK for an object to commit suicide  delete this

User · Answer

Well  in Component Object Model  COM  delete this construction can be a part of Release method that is called whenever you want to release aquisited object   void IMyInterface  Release         --instanceCount      if instanceCount    0          delete this

[c++] Is "delete this" allowed in C++?

Examples related to c++

Examples related to memory-management

Examples related to new-operator

Examples related to delete-operator

Examples related to self-destruction