Mixing up a "bag" of components with different ownership scheme

Started by
4 comments, last by phil_t 7 years, 7 months ago

Hello,

I maintain a series of components in a vector in which all of them are purely unique_ptrs in game object

But When I add some special types like Physics, I have to use a shared_ptr because

I can't clear the ownership of that type of pointer in the Physics Singleton while other objects

may retrieve that component when they need it.

So it must be shared.

The problem is when I get the component from the singleton, it is of std::shared_ptr type,

When I then add to the game object, because all components are unique_ptr type,

I get some errors.


Error    34    error C2784: 'std::unique_ptr<_Ty,std::default_delete<_Ty>> ComponentManager::AddComponent(std::unique_ptr<_Ty,std::default_delete<_Ty>>)' : could not deduce template argument for 'std::unique_ptr<_Ty,std::default_delete<_Ty>>' from 'std::shared_ptr<PhysicsMover>'    D:\Projects\C++\pinter\SimObject\Trolley.cpp    49    1    pinter

So except things like Physics, when the game object goes out of scope, they will delete themselves

But I really want to keep all components in one place, should I keep 2 sets of components in

the game object, one for singly-owned type, one for shared?

You see the above message because I first move the unique_ptr into the component manager, leave a raw copy there.

Then move that into the game object afterwards...


std::shared_ptr<PhysicsMover> l_physicsmover = PhysicsMover::getInstance();    
l_physicsmover->addMesh(this);
this->AddComponent(ComponentManager::getInstance()->AddComponent(l_physicsmover));

And I can't


std::shared_ptr<PhysicsMover> l_physicsmover = PhysicsMover::getInstance();    
 l_physicsmover->addMesh(this);
this->AddComponent(ComponentManager::getInstance()->AddComponent(std::move(l_physicsmover)));

BTW, if I convert a unique_ptr to a shared_ptr one type to another or vice versa, would it just bleach the original ownership scheme?

Thanks

Jack

Advertisement

Sounds like they should all be shared_ptr. You have a list of components that you can't make a strong guarantee of unique ownership about, so shared ownership is what you have.

Sounds reasonable. Hope not getting any memory leaks when it is in production

It will test it out anyways

Nup, I decided to add a dedicated interface for shared objects....

It is dirtier, but it fulfills my needs...

Thanks though

Jack

Are you sure it makes sense for the PhysicsMover to be a component in the first place? Based on Your description, it seems to me it's some kind of subsystem which might operate on gameobject components, but why would it itself need to be a component?

I can't clear the ownership of that type of pointer in the Physics Singleton while other objects may retrieve that component when they need it.

It's rare that you should need to use shared_ptr... especially in a game, object lifetime ownership should be quite clear.

I still don't understand your scenario - what code do you have that would be holding onto a Physics component beyond its game object's lifetime?

This topic is closed to new replies.

Advertisement