C++ concept

john5632

Please clear the below confusion; 1. Can you call "delete this;" inside a member function? 2. If Yes, What can you do after calling delete this?

Manfred Rudolf Bihy

It is allowed, but wreaks all kind of havoc depending on what the next statements are in your code. An object instance didn't instantiate itself, so it should neither delete itself. There might still be refernces pointing to said ojbect instance which would become undefined if the object instance would delete itself. Best Regards, -MRB

hmaz4629

u can do this but after this you cant access that mamber function or veriable which is being deleted....!~

Niklas L

You can do that, but with care! Afterwards you can not access any instance variables. This implies you can call class methods (declared static) and also other instance methods as long as they don't access any instance variables (in which case they are not truly instance methods anyway.) You can still access class variables (declared static). My recommendation is to not use it unless you really know what you're doing.

home

Albert Holguin

I think this is one of those things you can do but shouldn't.

jschell

hmaz4629 wrote:

u can do this but after this you cant access that mamber functio

Technically that depends on the exact nature of the function and maybe the compiler. I say maybe because I would suppose that most C++ compilers are going to generate static bindings for non-virtual methods simply because it produces faster code.

hmaz4629 wrote:

or veriable which is being deleted..

That is certainly unsafe but the actual impact depends again on the compiler and what the variable is and how the application works.

jschell

You can and it might even work. It however is always wrong.

David Crow

jschell wrote:

It however is always wrong.

Not always.

"One man's wage rise is another man's price increase." - Harold Wilson

"Fireproof doesn't mean the fire will never come. It means when the fire comes that you will be able to withstand it." - Michael Simmons

"Some people are making such thorough preparation for rainy days that they aren't enjoying today's sunshine." - William Feather

Niklas L

This can be used to clean up when implementing COM objects in C++. E.g. when the reference count is zero in Release(). It puts some constraints on instance creation though. You will not get away with automatic objects for instance.

home

_Superman_

Like others have said, you cannot access instance member variables after delete this. In addition, I would like to mention that if the object is created on the stack, it will crash. So before you do this you have to ensure that the object is created on the heap. You could probably do this on a singleton implementation.

«_Superman_» _I love work. It gives me something to do between weekends.

_Microsoft MVP (Visual C++)

Polymorphism in C

jschell

Odd. Myself I would consider the design that lead to that requirement wrong.

Stefan_Lang

You can, but you normally shouldn't. You'll destroy both the variables and the virtual function table (if you have one), so cannot access either. The only things you could still safely do is call static member functions or access static member variables. That said...: - What would happen if you allocated an array of objects of this type? -> crash! - What would happen if you allocated the object on the stack, not on the heap? -> crash! - What would happen if you allocated an object through malloc, a pool allocator, or any other non-standard memory allocator? -> most likely crash - What would happen if you allocated an object of a class derived from this one? -> might work, but could have undesired effects as you're calling the derived class' delete function which may do more than you intended The only way to define such a class in a way that prevents any of the uses above is by protecting access to all the constructors and the destructor, and then provide create() and destroy() functions instead. Or use a friend helper class that does it for you (e. g. smart pointer or factory)