Not many can claim 25 years on the Internet! Join us in celebrating this milestone. Learn more about our history, and thank you for being a part of our community!
Either create a list that contains obj1 collided with obj2 and use it or store another pointer list for a troll that stores all other collided object so you can eaisly clear upon desturction ~trol()
{
fir (int i=0; i < listcount; i++)
if (object!=0) object->colidedeith = 0;
Something like that linked kist are helpful
On 1/18/2019 at 5:50 AM, Hodgman said:Pointers considered harmful. Handles are the better pointers. ?
https://floooh.github.io/2018/06/17/handles-vs-pointers.html
Weak pointers, and/or ref counting are overkill. Even raw pointers on 64bit platforms are overkill. Integer-based handles actually have a lot of advantages over pointers ?
After reading the article, I would be interested in learning more about handles. The actual nuts and bolts. I can't find any tutorials or examples.
Could you point me to something introductory even if it's a book or article?
Mike
After reading the article, are you finding it troublesome to get started and getting rid of your pointers?
A handle is just a unique integral number assigned by some authority, a manager. The outside world must not induce anything from the handle itself.
In order to get the contents behind a handle, you must ask a manager, which will do a lookup (implementation of which is private and hidden!). Every time. You don't store pointers to the returned values. You don't care and mustn't care where they are in memory.
Think about it this way: Instead of pointing your finger towards a troll that attacked you and risking that the troll gets lost behind a wall (and aliens abduct it from there) so you'd be pointing to a void space where you just think a troll should be, just remember the number tattooed on the troll's forearm. Every time, every frame, when you want something with it, ask the Troll Registration Bureau: "Hey, is troll XY still alive? And if yes, where is it?"
The nuts and bolts would be how to assign unique handles, how to organise the contents in memory, how to to optimise the cache access... however first you need to set up the interface and throw in any basic implementation, and only optimise in case it is a bottleneck.
The troll manager might have a hash-map<Handle,Troll> style dictionary, in a naive implementation. Every time it's asked, it'll look into the hash-map and return nullptr if it doesn't find anything (or anything alive). And if it does find it, it can actually return a POINTER (!) but you must not store it for later use. Just use it and forget it. Next time, it might return a different pointer for the same handle, for example if it did some kind of defragmentation.
On 1/21/2019 at 7:57 PM, too_many_stars said:After reading the article, I would be interested in learning more about handles. The actual nuts and bolts. I can't find any tutorials or examples.
Could you point me to something introductory even if it's a book or article?
Mike
Just use C++ idioms (RAII, smart pointers) and you should be fine for 99% of projects. Smart pointers are a kind of handle anyway, so you you can say you're using handles too.
https://www.fluentcpp.com/2017/08/22/smart-developers-use-smart-pointers-smart-pointers-basics/
edit: I only scanned that article but there are many
On 1/18/2019 at 10:02 AM, Gnollrunner said:So the actual memory for the Troll stays around but it's flagged to dead. When the Troll is no longer being referenced by anything, it's collected by the smart pointer system.
This is nice, building on that idea :
You can make a nice explosion effect animation when dies, meanwhile every frame is used to compare all pointers and remove if needed.
The animation need to be as long as needed before removing itself.
Better you also have zones in your map so you dont have to check to much.
5 hours ago, Sound Master said:This is nice, building on that idea :
You can make a nice explosion effect animation when dies, meanwhile every frame is used to compare all pointers and remove if needed.
The animation need to be as long as needed before removing itself.
Better you also have zones in your map so you dont have to check to much.
This is normal smart pointer behaviour.
Linking object destruction to actor death does not make sense.
On 1/18/2019 at 10:21 AM, too_many_stars said:Is there a design pattern (hopefully not too obtrusive), algorithm, or a way upon object destruction to notify every other object that's pointing to the destroyed object that it's been deleted so i can NULL the pointers?
Make 2-way pointers system. It works exactly as you said - warrior storing poiner to troll together with adding poiner to themself into troll's notifications array. Into destructor troll send notifications using it array.
There is yet for you to consider if Troll could be a reinstanced object, since, newing and deleting objects all around the program is not the best way to go as I learned in my experience about good and bad program codes.
So if you could make Troll a reinstanced object, meaning you are ready for say, 100 Trolls trough the life time of program at a time at most. Then along with pointer to a Troll (or index of a Troll instance) store also unique ID of Troll in referencing objects, and make this ID always new number upon deletion-reinstancing inside a Troll instance, with 0 being shared ID for "no-instance".
So if referenced Troll (through pointer or index in array) contains 0 or an ID number that does not equal referenced stored ID number, you know Troll has been destroyed, and there is no instance or not a valid instance of troll on the pointer (or index in array).
I assume you have a handling logic for that already, so do not check pointer for NULL only, but after-enstrenghten the check by
if (this->m_pTroll!=null)
if (this->m_iTrollid==this->m_pTroll->m_iTrollID)
{
....
}
else
this->m_pTroll=NULL
2 hours ago, JohnnyCode said:There is yet for you to consider if Troll could be a reinstanced object, since, newing and deleting objects all around the program is not the best way to go as I learned in my experience about good and bad program codes.
I believe that placement new with a good memory manager can help in this situation 
22 hours ago, Fulcrum.013 said:Make 2-way pointers system. It works exactly as you said - warrior storing poiner to troll together with adding poiner to themself into troll's notifications array. Into destructor troll send notifications using it array.
This looks a bit like the Observer design pattern.
6 hours ago, _Silence_ said:This looks a bit like the Observer design pattern.
It really extension of Observer, where observing works on both direction, and in common case compoonent can observe and be observed by any other component. It widely used for objects lifetime managment and protection from dead references, for wich serve much flexible and efficiently then GC
6 hours ago, _Silence_ said:I believe that placement new with a good memory manager can help in this situation
Say more overloaded new and delete operators that take actual memory from typed segmented pool do it so fast, so allocation enought fast ever for bullets fired by Vulcan cannons. Chatacters lifetime so long and spawns happends so rare, so in most cases it no reasons to worry about allocation/deallocation speed. Only reason to use O(1) allocation pools for characters is to meet another requitmenst of real time software reliability - only way to warranty presence of required memory for buffers is to have it allocated on start of simulation.
