I've been mulling over use of unique_ptr vs shared_ptr vs own_solution. I've discounted the latter as I'll almost certainly get it wrong, but I have a problem with both unique_ptr and shared_ptr in that neither captures precisely what I want. I want to create a resource manager which explicitly owns a resource, however I'd like the resource manager to also hand out references to the resource.
If I use unique_ptr in the resource manager and hand out raw pointers there's the possibility they could escape elsewhere (though this would be against the class "contract" I suppose). If I use shared_ptr and hand out weak_ptr, there's nothing stopping a caller from converting the weak_ptr to a shared_ptr and storing that, thereby potentially creating a cycle or worse, a resource living beyond the lifetime of the resource manager. So I suppose what I'm looking for is a deferencable weak_ptr that cannot be converted into a shared_ptr.
Or am I just looking to enforce the contract with some strongly worded comments in the code?
Thanks for any thoughts you might have on this.
Smart pointers like shared_ptr and unique_ptr are a good tools when you have owning pointers.
But for non-owning pointers, i.e. observing pointers, using a raw pointer is just fine.
In your design, I think the resource manager is the only "owner" of the resources, so you could simply have some form of smart pointer inside the resource manager. For example, the resource manager can have a std::vector<std::unique_ptr<Resource>> as a data member, or even a simpler std::vector<Resource> if your Resource class is designed to be correctly storable in a std::vector.
Then, the resource manager can give to the outside just non-owning observing pointers, and raw pointers (or C++ references) are fine for this case.
Of course, it's important that the lifetime of the resource manager exceeds that of the "resource clients".