Hi,
I was just think about how I could implement a 'delete list' where I create an iDeletable interface and have every object I have in my game extend it and then keep a delete list where every time I create a new object using new I could push it onto the list and then I could just cycle through it at close and delete all the objects I have created instead of having to put delete thisObject in various places. The queue would be static or something so the object could remove itself from it if it was deleted somewhere else.
Is this a really stupid idea?
I was just thinking it might make things a bit cleaner so if I remove a line of code the has new I do not have to find the relevant delete call.
Delete List
Hi,
I was just think about how I could implement a 'delete list' where I create an iDeletable interface and have every object I have in my game extend it and then keep a delete list where every time I create a new object using new I could push it onto the list and then I could just cycle through it at close and delete all the objects I have created instead of having to put delete thisObject in various places. The queue would be static or something so the object could remove itself from it if it was deleted somewhere else.
Is this a really stupid idea?
I was just thinking it might make things a bit cleaner so if I remove a line of code the has new I do not have to find the relevant delete call.
Sounds like a DIY form of garbage collection.
You'll be adding a tiny bit of overhead to every object, and you'll still need to do some housekeeping to register the objects for eventual deletion.
The biggest benefit is that you can have deletion of objects running in a background thread rather than right in the middle of busy processing. A few downsides include the difficulties of debugging (especially if you run it asynchronously), multiple inheritance for every object, and increased risk of accidentally using a dead pointer.
You might look into existing garbage collection systems, or using the existing garbage collection in .net if you are developing on Windows.
If its not for garbage collection its definitely useful for detecting memory leaks.
How does the list determine if a object will get deleted or not?
How does the list determine if a object will get deleted or not?
Garbage collection also will not work for unmanaged resources which I believe the original poster was referring to by his objects.
There is no need to delete objects when the application shuts down. That just takes processing time for nothing (OS will do it for free). If the object represents actual resources that need to be closed to be 'safe' (ie. file handles). Those should be handled explicitly through general good design.
You shouldn't be using a lot of new and delete in your program anyway, and when you do new up something, the memory should be held by smart pointers, which do the deletion for you, at the right time.
There isn't any usefulness in doing what you are proposing. Your program may run out of memory due to not performing deletions soon enough, or the behaviour might be wrong due to destructors not being run at the right time, which might mean file handles not closed yet etc. The burden of deletion is properly solved through RAII techniques.
There isn't any usefulness in doing what you are proposing. Your program may run out of memory due to not performing deletions soon enough, or the behaviour might be wrong due to destructors not being run at the right time, which might mean file handles not closed yet etc. The burden of deletion is properly solved through RAII techniques.
From what I've been told (I'm relatively new to this game stuff, myself) you'll want to do most (If not all) of your object creation in the initialization phase of your program. Dynamically creating and deleting objects always adds the most overhead to your project.
Say you're keeping track of a list of entity objects in a game. It's typically better practice to load a bunch of these objects as empty objects at init and then just change out the data they hold as your game 'creates' and 'destroys' entities. So you're essentially just reusing the same objects over and over again rather than destroying and creating new ones. Just add an IsDead member and set it to true when you want to 'destroy' the object so the program knows this object is safe to re-purpose with a 'created' objects data.
And If you do need to dynamically create or destroy lists of complex objects after init, plan on adding a load screen with a nice progress bar. And while you're at it you may want to do your mid-program object creation and deletion on a separate thread.
Say you're keeping track of a list of entity objects in a game. It's typically better practice to load a bunch of these objects as empty objects at init and then just change out the data they hold as your game 'creates' and 'destroys' entities. So you're essentially just reusing the same objects over and over again rather than destroying and creating new ones. Just add an IsDead member and set it to true when you want to 'destroy' the object so the program knows this object is safe to re-purpose with a 'created' objects data.
And If you do need to dynamically create or destroy lists of complex objects after init, plan on adding a load screen with a nice progress bar. And while you're at it you may want to do your mid-program object creation and deletion on a separate thread.
Thanks for all the replies,
I've never looked into smart pointers before but I have heard of them so I think now might be my time.
I think in all a bit of a rubbish idea but thanks all for your thoughts, I was just being a bit lazy.
Part_E you are right object pooling is good if there are lots of objects, I've used it before so I might have a look back over my old stuff.
And Vectorian the idea was not so much with shutting the application down but exiting the current game and restarting etc.
Cheers I'm now going to investigate smart pointers and [color=#1C2837][size=2]RAII.
I've never looked into smart pointers before but I have heard of them so I think now might be my time.
I think in all a bit of a rubbish idea but thanks all for your thoughts, I was just being a bit lazy.
Part_E you are right object pooling is good if there are lots of objects, I've used it before so I might have a look back over my old stuff.
And Vectorian the idea was not so much with shutting the application down but exiting the current game and restarting etc.
Cheers I'm now going to investigate smart pointers and [color=#1C2837][size=2]RAII.
Thanks for all the replies,
I've never looked into smart pointers before but I have heard of them so I think now might be my time.
I think in all a bit of a rubbish idea but thanks all for your thoughts, I was just being a bit lazy.
No, it's not "a rubbish idea". It's a well-established idea. It's just that people who are very experienced have already done it, and you should consider reusing their work.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement