delete this;

If you''re asking when the destrutor for a class is called, it will occur when you call "delete this;". This is valid, as long as you don''t have any other pointers lying around that will try to access it. You can put stuff into the destructor to make sure those pointers are nullified, which is another reason to use a linked list for this kind of stuff. Don''t try to modify member variables after you delete the object. In debug, you will get access violations, and in release it will gradually break down until you don''t know what is wrong. Don''t attempt to have objects delete themselves until oyu are perfectly clear on the results of doing it.

I thought you couldn''t make objects delete themselves. I tried it once and crashed my program pretty bad . It is good to know that it is possible, because it will greatly simplify some of my code too.

--------------------


You are not a real programmer until you end all your sentences with semicolons; (c) 2000 ROAD Programming

You are unique. Just like everybody else.

"Mechanical engineers design weapons; civil engineers design targets."

Yanroy@usa.com

Visit the ROAD Programming Website for more programming help.

I''m not sure, but I think your worst fear about this thing would be correct. delete works like free(), so the destructor is called on the spot and the object is deallocated. HOWEVER, I think the function keeps running, because the class function isn''t actually part of the class - it is located somewhere else in memory and only ends with return(). The function refers back to other class members through this pointer.
I think you might even be able to access some members of the defunct class and get valid data, because delete() doesn''t torch the data, it only sets that block of data as deallocated (the pointer still points there, unless you reset it to NULL). Of course, you shouldn''t try accessing dead data - that block may be already in use by some other function... If delete() is the last thing you call in the member, it should play out safe enough. Tell me if I''m wrong.

I''m using a "delete this;" in my code and it works fine. I don''t know if the function would keep running, but I do know that I wouldn''t chance it. If you are going to have something delete itself, then have the function return as quickly as possible. Or, try it out. See if you can make another function call after deleting this. I''d be interested to see what actually happened.

You can probably do that, but keep in mind it is considered very bad programming technique. You should ALWAYS keep your deletes in the same module/class that newed it.


- Houdini

Delete this is not a bad programming techniques. Remember the Interface classes?

void ISomthing::Release()
{
m_nRefCount --;
if (m_nRefCount <= 0)
delete this;
}

I''m implementing an engine that uses classes with a virtual function that allows you to deconstruct it with a function call rather than just deleting. This is necessary because all the objects are derived from a base class and are thus passed around as their parent class in order to define general functions that will work no matter what derived class it is. However, if you just say "delete ptr;" where ptr is a pointer to the object, which is defined as a pointer to the parent class, it will only call the deconstructor for the parent class. However, if you call the virtual function, it calls "delete this;" which calls the deconstructor for the derived class AND the parent class. This is the desired effect, and thus, this is how I implement it. Whether or not it is "good programming practice", it is unfortunately the easiest way I''ve found to implement this functionality. That''s just my two cents :-D

Really? I thought putting the word virtual in front of your deconstructor was the easiest thing...
About delete this;
You should think of a method as a functon that gets a ptr to the object it belongs to as the first parameter, something like:
void MyClass::MyMethod(int h)
{
m_MyValue += h;
}
becomes:
void MyMethod(MyClass *this, int h)
{
this->m_MyValue += h;
}
thus 'delete this' is definetly possible, but is considered bad programming style because the code that has constructed the object may not know that the object has been deleted. However if this is to be done you should be quite clear on the issues that arise and what really happens.
Turtlenet:
I know MS has implemented their COM-objects this way and it probably has it's reasons (like compatibility with other languages and stuff), but I think that a better reference counter is described in an article here at gamedev.net (don't recall the article's name nor the author's ). Instead of one you have two classes. One resembles the IUnknown MS interface in that it has a reference counter and is the baseclass of all reference-counted objects, the other is a template class that contains the ref-counted object and some operator overloading´(like = -> and on) and it makes all the calls to AddRef() and so on to the object and deletes it finally. In that class you can also implement a IsNull() method to check if the object has been deleted.

/Andreas

Edited by - amag on January 22, 2001 12:26:45 PM

Hmmm.. I never actually thought of putting virtual in front of the deconstructor. It''s too obvious. It didn''t seem like it''d work :-)

That''s what I get for trying to be overly clever...oh well, looks like time to go modify some code! hehe geez