An unique OOP question

[Robert Kosek]

I have been programming alot in the last few days with Asphyre, rewriting an old formerly vaporware project of mine. In some oo coding I have one pressing question: Can an object free itself?

Psuedocode Example:

if lifespan <= 0 then begin
  List.Remove&#40;Self&#41;;
  Self.Free;
end;

So for instance within the Update call the object could free itself if need be, or would I need to make a function to run through and clean out all the dead objects? Just wondering so I don't, you know, completely mess everything up.

[technomage]

the problem with objects freeing themselves is referencing. If any other object has a reference to that object , be it a list or another object how will you tell it that it has freed? Your worst case would be a rather funny access violation when trying to access the freed object.

You could use an event to trigger a nofification that the object has been freed , my preference would be to set a flag on the object and clean up elsewhere. For example one of my projects the main game engine cleans up the game object list removing "dead" objects.

I think you'll find its "good practice" for objects to be free's by the owner.

[Robert Kosek]

Well, it was a theory. I'll just write a junk cleaning function, since the flag is already present. I was curious though, yet nothing else referenced the object.

[dmantione]

Yes, an object can destroy itself. It is seldom, but it can be usefull in certain cases.

[WILL]

Ah, I know exactly what Robert is thinking.

I had been trying this with my first game that I did using Object Pascal but never got it to work without problems. Of course I was rather new to OOP at the time, but I've never reapproached it since then.

Simply out of curiosity though, I'd love to see how it would be done 'properly' even if thats not the way one should term it. :thinking:

[Robert Kosek]

Well, someone at Afterwarp suggested implementing the "Factory Method Pattern". Don't know if this would work, but I'm moving along without it.

For the latest post on what I'm doing, as well as a post with Turbo Delphi units (MPL licensed) for 2D Vectors and Colors (with operator overloading) you can hit my blog. I'll make a project announcement a bit later as I near getting something viable for my game.

[tanffn]

Sorry, I don’t see the problem here.. I assume List is the same instance as of its parent.
I think you can also call freeandnill(self) (as you can’t self:= nil).

The only problem may accrue if it’s multi-thread and several processes are using that same intense (then you can simply add a lock to make it thread-safe).

[marmin]

Ask the free pascal team.. they must know the answer.

[Fran]

In fpc and delphi, it's not safe to have an object free itself. That's because of some code optimisation that's happening under the hood.

However in fpc it's safe to do so with tobjects and in delphi 2006 with advanced records.

Note that delphi's tobjects do not work, don't even attempt to use them, they are totally buggy (i still don't get why they didnt fix the tobjects rather than introduce the new advanced records, it's almost the same thing). And fpc doesnt support advanced records so... this little trick will be hard to implement if you're trying to use cross compiler code.

Just make 101% sure you do not access any of the tobject's(record's) data once it's freed, not even methods.

If in doubt, check the dissassembled form of your software (ctrl+alt+c in delphi) while debugging.

It can be a useful coding practice, i know i use it once in a while! Good luck!

[TheDon]

Can you explain the TObject's problem in detail and what you mean with "don't even attempt to use it"? Instancing a TObject directly is not usefull, you cannot do much with it and everything else is derived from TObject.

TIA