# Component stays alive when the GameObject goes out of scope

This topic is 919 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

## Recommended Posts

I've got a component manager that stores a reference to the component,

this component is created as a new instance or obtained thru a singleton.

and data type for it is boost::shared_ptr.

void Truck::Create()
{
SimObject::Create();

boost::shared_ptr<Arrivals> l_arrival = Arrivals::getInstance();

CMinMax<float> arrivalTime(10000.0f, 20000.0f);
this->FindCompoentByType<Arrivals>()->PostRequest(*this, arrivalTime.GetRandomNumber(), arrivalTime.GetRandomNumber());


When the component is first created, the strong count is 4,

1st from the getInstance itself

2nd from l_arrival

which is quite strongly referenced.

When the game exits, the game object dies,but the component stays alive,

the arrival component is basically an observable by the game object (the truck),

the truck dies, the observable has no observers to deliver messages to,

so the program crashes.

I like the idea of self-managed pointers, but it seems not applies here

Also the arrivals component has a threadpool in itself,

but the destructor of arrivals is too late to destruct, when it dies, all pending requests will be purged.

Any better idea for me?

Thanks

Jack

Edited by lucky6969b

##### Share on other sites

When the game object store a shared instance of the physics mover,

I am wondering, if the game object uses a unique_ptr to store components,

in order to keep the interface consistent, should I make up 2 separate kinds of components,

one sharable to be used by components like astar, timeastar and physics

and non-sharable (solely owned) by one object, like the state machines?

the common data type is a Component, so that I can add sharable and non-sharable

components to the same container?

The only problem is when the container is a unique_ptr, it is not sharable in the first place....

// Step 2 ---- should be a singleton, shared by many objects
PhysicsMover* l_physicsmover = PhysicsMover::getInstance();

Edited by lucky6969b

##### Share on other sites

Sorry I haven't responded, I've been AFK a few days.

First, to answer your question: unique_ptr is just a convenient way to automatically delete objects when the pointer goes out of scope, but it is not essential to use it. You can just store raw pointers and delete the objects at the appropriate time (e.g. in the game object destructor). You would need to determine which components you own and should delete, and which components are shared. Even though it's technically possible however, I would not mix objects with different ownership together in one container, seems like asking for trouble.

Second, I will ask some questions of my own if you don't mind. Why is PhysicsMover a shared singleton? If it makes sense for it to be a singleton, should it even be a component? Maybe it should be a subsystem (that acts on components) instead? Astar doesn't really seem like a component to me. If you have a single shared Astar component, where would the calculated path be even stored? How about a Pathfinder component instead, which can have parameters like pathfinding speed vs. accuracy, and uses the Astar subsystem (or can use any associated pathfinding system) to calculate paths that it can store?

1. 1
2. 2
3. 3
Rutin
13
4. 4
5. 5

• 26
• 11
• 9
• 9
• 11
• ### Forum Statistics

• Total Topics
633697
• Total Posts
3013404
×