使用 unique_ptr 并返回一个引用，或者我应该使用 shared_ptr 并在需要时制作副本

Question

I have a cache that stores unique ptrs of objects in an unordered map and returns a reference of the object for users of the cache. It works as it should, storing the objects until they go out of scope.

The cache is implemented as follows:

store objects in cache:

template<typename T>
template<typename... Args>
void ResourceCache<T>::add(const std::string& name, Args... args)
{
    m_cache->try_emplace(name, std::make_unique<T>(args...));
}

get object from cache:

template<typename T>
T& ResourceCache<T>::getCachedElement(const std::string& name) const
{
    auto it = m_cache->find(name);

    if(it != m_cache->end())
        return *it->second;

    throw "resource not found";
}

But now I walk in to the problem that a reference is not always what I would like to get from the cache, per example:

I have the following object:

class GameObject
{
public:
    void translate(const cheetah::Vector3f& position);
protected:
    Quaternion m_rotation;
    Vector3f m_position;
};

lets say I want the object to have a Texture, currently the only way for me would be to add a member reference

Texture& m_texture

This would result in me having to either

1. Pass a Texture to the constructor for each object, even if they dont need a texture.
2. Create a TexturedGameObject that inherits from the GameObject and adds a Texture member and constructor.
3. Use shared pointers instead of unique pointers and be able to return a copy

Now my question is

What would be seen as best practice in this specific situation? should I use one of the above options or have I missed an even better option?

I know my question is not the most specific but I am learning c++ by myself and it would be nice to get someone elses view on this.

Answer 1

Assuming ResourceCache holds Texture , here's my thoughts. There does not seem to be one best solution in general.

1. Pass a Texture to the constructor for each object, even if they dont need a texture.
   • You would need to pass a dummy object so if you want to go with this way, I would suggest keeping it as a raw pointer instead
   • By doing this you can check if it really has a pointer or not since it can be nullptr
   • NOTE Either reference or pointer, you should make sure that ResourceCache outlives all GameObject - the lifetimes must be managed manually
2. Create a TexturedGameObject that inherits from the GameObject and adds a Texture member and constructor.
   • This could be an option but I think this is more a design issue
3. Use shared pointers instead of unique pointers and be able to return a copy
   • This would work fine
   • Safe (no issues like double-deletion/dangling-pointers)
   • Shared pointer has overhead