Thread: this Pointer

Originally Posted by vb.bajpai

not by new[], nor by placement new, nor a local object on the stack, nor a global, nor a member of another object; but by plain ordinary new - where are global objects stored?

This is one of those platform specific items, I believe. If you didn't not create an object via new and it's global, then you cannot delete it. It's stored somewhere special. Just trust that.

Originally Posted by vb.bajpai

You must be absolutely 100% positive sure that your member function will be the last member function invoked on this object. - how is this possible when delete this itself will call the destructor part of object, so the func. calling delete this will be last?

What they mean is don't do this:

Code:

someObject->dodelete(); // Delete is called here
someObject->dosomethingelse(); // Stupid.

Originally Posted by vb.bajpai

Naturally the usual caveats apply in cases where your this pointer is a pointer to a base class when you don't have a virtual destructor. - how can a this pointer point to base class ? and if such is a case, is this too polymorphic?

Frankly, I don't think you should be doing delete this anyway.... There's just too much of a risk to break the code somehow. If you're confused about any aspect, I would recommend you don't do it.

Originally Posted by vb.bajpai

Naturally the usual caveats apply in cases where your this pointer is a pointer to a base class when you don't have a virtual destructor. - how can a this pointer point to base class ? and if such is a case, is this too polymorphic?

for example,

Code:

class Base
{
public:
    ~Base() {}
    void DeleteMe() { delete this; }
};

class Derived : public Base
{
public:
    ~Derived() {}
};

int main() 
{
    Base *pB = new Derived();
    pB->DeleteMe();  // this is not good.
}

In this case, ~Derived() is never called. to fix this you should make ~Base() virtual.

Originally Posted by MacGyver

Frankly, I don't think you should be doing delete this anyway.... There's just too much of a risk to break the code somehow. If you're confused about any aspect, I would recommend you don't do it.

In this specific instance, agreed. No offense, vb.bajpai, but I don't quite think you're ready for this yet.

That said, as long as you control creation of the object (.i.e. with a private constructor and a static Create() member that ensures it's created with new) 'delete this' is a perfectly valid idiom.

Originally Posted by Daved

>> In this case, ~Derived() is never called.
In practice maybe, but technically it's just undefined behavior. It could have other consequences.

damnit, I thought it might be undefined behaviour. Should've gotten off my ass and looked it up first...