Dealing with unique_ptr in containers

Question

I have a vector of unique_ptrs which point to Models, Meshes, etc like this:

std::vector<std::unique_ptr<Model>> mLoadedModels;

I choose unique_ptr because it automatically frees the data upon vector destructor, and also because later on if I need to for example reload all the models (due to OpenGL context tear down/created) I can just internally in my resource manager reset() and make it point to a new Model instance and it wouldnt affect the rest of the system.

My question though is, how would you share the contents of the vector with other systems? You cant just pass the unique_ptr around, because that would change the ownership (due to its unique_ptr), and I want sole ownership in the rersource manager.

The solution I came up with is the following, to wrap the access in the following struct:

template<typename T> struct Handle { Handle(std::unique_ptr<T>& resource) : mResource(resource) { } T& operator*() { return mResource.get(); } const T& operator*() const { return mResource.get(); } T* operator->() { return mResource.get(); } const T* operator->() const { return mResource.get(); } private: std::unique_ptr<T>& mResource; }; typedef Handle<Model> ModelPtr; ModelPtr GetModel(const std::string& modelName); // example: ModelPtr monkey = GetModel("Monkey"); monkey->dance(); // reload resources, and then monkey dereferences to the new Model instance

It feels abit gimmicky though, surely theres a better, more straightforward solution to this?

Use shared_ptr if you need shared ownership. You could then hand out weak_ptrs to observers. — Praetorian
– Praetorian, Commented Jul 19, 2013 at 18:54
Handle should obviously be named unique_ptr_ptr. Kidding aside, your Handle will be invalidated when the vector resizes. — Casey
– Casey, Commented Jul 19, 2013 at 18:54
@Casey really, it should be shared_unique_ptr to deal with lifetime issues (I kid). — Yakk - Adam Nevraumont
– Yakk - Adam Nevraumont, Commented Jul 19, 2013 at 19:00
@Yakk I like to use shared_unique_ptr* to cover all my bases. — Casey
– Casey, Commented Jul 19, 2013 at 19:27

Yakk - Adam Nevraumont · Accepted Answer · 2013-07-19 18:59:26Z

There is a simple solution to this.

Pass around vec[n].get() -- raw pointers. So long as you don't store them, and always get them back from the owner, and the owner doesn't destroy them while you are using them, you are safe.

If you aren't willing to follow that level of discipline, what you need is a std::shared_ptr in the vector, and pass around and store std::weak_ptrs. The weak_ptrs will auto-invalidate when the last shared_ptr goes away (and by policy, the only persistent shared_ptr is the one in the owning vector).

This has the added advantage that if you are in the middle of doing work on an element and the vector clears itself, you don't segfault. You access a weak_ptr by .lock(), which returns a shared_ptr, during whose lifetime the raw pointer is guaranteed to be good.

The downside is that this ups the cost, the upside is that it allows for weak shared ownership and lazy notification of invalidation.

I do need to store them though, for example my Model stores a MeshPtr and a MaterialPtr, etc. I want to make it as transparent as a pointer also, with weak_ptr you have to do lock() every time you want to access the resource right?
What about passing around a vec& and then an index number, wrapped in a struct like the Handle``
@KaiserJohaan First, There is rarely a good reason to store references in persistent objects. Second, "transparent as a pointer" is no good if the pointer can be made invalid at any point. .lock() defines a scope in which the pointer cannot be made invalid and can be safely used. It might be overkill if you can prove that the pointer in question will only be destroyed at certain points...
Is there no good alternatives to avoid having to perform .lock() every time you access it then?
@kaiserjohaan sure: have sensible lifetime and access rules. Who owns it provides it, and destruction happens at known times that does not overlap with non owning pointer lifetimes.

Stuart Olsen · Accepted Answer · 2013-07-19 20:11:29Z

0

Use a plain std::vector <Model> and hand out raw pointers to the individual elements. You shouldn’t need to make it any more complicated than that unless you need dynamic polymorphism or expect references to the Models to outlive the vector.

answered Jul 19, 2013 at 20:11

Stuart Olsen

4962 silver badges7 bronze badges

2 Comments

Yakk - Adam Nevraumont Over a year ago

The pointers to Model are then invalidated if std::vector resizes, so they cannot persist over any code that could modify the length of the std::vector.

Stuart Olsen Over a year ago

@Yakk Ah yes, that’s all too easy to forget. Now, depending on how the container is manipulated, std::deque <Model> might be appropriate, but probably the std::unique_ptr/get solution is the best.

Collectives™ on Stack Overflow

Dealing with unique_ptr in containers

2 Answers 2

5 Comments

2 Comments

Hot Network Questions

Collectives™ on Stack Overflow

2 Answers 2

5 Comments

2 Comments

Related