object self-destruction

[John87Connor]

hi everyone,

i´m asking myself if it is allowed to let an object self-destruct. take a look at this example:

struct Item;

struct MyContainer
{
		vector<Item*> items;
};

struct Item
{
		int data1;
		float data2;
		// ...
		
		void DestroyMe(vector<Item*>& items)
		{
			for (int i = 0; i < items.size(); i++)
			{
				if (items[i] == this)
				{
					items.erase(items.begin() + i);
					break;
				}
			}
		}
};

when object xyz calls its method "DestroyMe(...)", and the code reaches the line items.erase(...), technically that object xyz doesnt exist anymore (am i right??), so how can then the function "DestroyMe(...)" progress with the line "break" and subsequently freeing the stack memory of the function call??

thanks for all your answers in advance !!

[Repeater]

All instances of a class share the same function code. There is an extra, hidden parameter passed in. The function:

void DestroyMe(vector<Item*>& items)

could be thought of as
void DestroyMe(vector<Item*>& items, Item* this)

The function code exists completely independently of any one class instance. If the this pointer becomes in some way invalid during the function call (for example by the object it points to being destroyed) that has no effect at all on the stack. There will only be a problem if the function subsequently attempt to use this or any of the member variables.

In your example code above, the item's destructor code will be called when it is erased, but since the very next line is a break; and the function returns, I'd expect this to not cause any problems. Of course, something called this Item::DestroyMe function, so whatever called the function presumably believes it has a valid Item object - it must do, in order to have called this function. Hope that caller doesn't expect to use the Item object ever again.

Here is a related question in the C++ FAQ: https://isocpp.org/wiki/faq/freestore-mgmt#delete-this

Of course, the example code you've written above is, I would argue, bad design; an object shouldn't know or care about the container it may or may not be part of, and ALSO there is a casual assumption amongst C++ programmers that objects won't destroy themselves - people will assume objects stay alive under they fall out of scope or have delete called on them. But this is just example code in which you're experimenting, and experimentation is always educational.

I'm sure you can think of other ways this could subsequently go wrong, amplified by the fact that you're making the vector do the deleteing. Did you call this on a reference to the Item in the vector, or through a pointer, so do you have a dangling reference now, or a dangling pointer, or maybe you've got an invalid iterator now but maybe not (what if the Item wasn't found and didn't get deleted?) etc etc.

It's educational, and a very bad idea :)

[Ganado]

(If I'm understanding the premise correctly)
You have a vector Item pointers, not a vector of Items.
Calling erase on a vector of pointers only removes the pointer, not the data it points to.

[Repeater]

Ha, so it is. Everything I said applies if it was a vector<Item> , not vector<Item*>.

[John87Connor]

@ repeater:

thanks for your description.
yeah, that example is just for educational purposes, i´ve heard this before that in c++, member functions actually have another invisible argument (either a reference or a pointer) in which the object itself is passed through automatically ... but i wanted to be sure hence the question :-)

and of course its bad design, i simplified the problem quite a lot ... instead of raw pointers, it´s a vector<shared_pointer<Item>> (but its ugly to read and can make possible forum members turn away ^^) and the DestroyMe() function actually accesses the vector<...> by calling another singleton class "container" (actually its a "universe" class containing a shared_ptr vector with "object" items [ships] which are actually themselves scene graphs made up of nodes and use some other object pointers as "parent object", i´m trying to get a 3D scene with space ship models following another bigship to work ... but i think i have to rethink the whole design, moving over to a "kind-of" ECS).

[Repeater]

(either a reference or a pointer)

Pointer. Named this. It's actually a C++ keyword ( https://en.cppreference.com/w/cpp/language/this ).